Random Thoughts on the Provider Pattern

The basic problem is of course that not only does the business logic become harder to read, but maintaining the crosscutting concerns becomes painful -- they're not contained in their own modules, they're instead scattered throughout the rest of the application. AOP seeks to place crosscutting concerns into their own modules, something they call aspects -- something that to me sounds very much like a provider.

Now I don't want to get into join points, pointcuts and weaving too much, except to say that weaving is the process of injecting the advice in aspects into join points -- basically getting the centralised logging and transaction code where it's supposed to be. Wikipedia lists five possibilities for weaving...

• A source pre-processor.
• A post processor that patches binary files.
• An AOP-aware compiler that generates woven binary files.
• Load-time weaving.
• Run-time weaving (trap each join point at runtime, and execute all relevant advice).

The first four are beyond the abilities of a lowly C# developer, but the fifth one there rings a bell. By using providers, we've identified our join points with generic provider code. The advice in our provider is weaved into the application code when the generic provider code is reached. Maintenance of, revamping, or even replacing crosscutting concerns becomes much, much easier -- as long as you don't want to change the provider interface.

Of course, the core business logic is still obfuscated with the generic provider code, so that goal of AOP isn't fulfilled by the Provider Pattern at all. But at least it's easier to maintain to some degree.

Does any of this make sense? How about a point?

Well my point I guess is this. In defining the Provider Pattern perhaps some of this AOP language can be adopted. It seems to me there is a whole swag of named concepts in AOP that relate closely to what the Provider Pattern actually does. Thoughts?

Post a comment