The patterns & practices group at Microsoft just announced the Policy Injection Application Block. The basic idea is that you can define a set of policies and handlers that will execute before and after certain policy-enabled methods. This will allow you to perform such tasks as validation, exception handling, authorization, etc. without having to write the same sections of code over and over in every method.
The main benefit (as I see it) is the separation of concerns. How many times have you worked on a project where someone told you, “Make sure you call this method at the beginning of every method that does _____.” or, “Make sure you put this specific code around your code to handle exceptions.”? It’s hard for everyone on a team to remember all of these little tricks, and you also run the risk that people on the team won’t always do everything correctly. My boss always says that we as developers need to “get out of the plumbing business” and write code that actually does something meaningful from a business perspective, and this will definitely help accomplish that goal.
But in reality, the first thing I thought of when I first heard about this was that many people will probably find many ways to misuse and abuse this application block. By giving the people more power, you’re also giving them more power to screw things up. I’m sure there will be some interesting anti-patterns with this application block.