Discovered ContextBoundObject a few weeks ago. Its been there in the framework all along but has remained elusive for me. I knew something like the ContextBoundObject was in the framework, since there was a lot of talk over Aspect Orient Programming just after .NET went live, but I just never made the connection.
When you create an object that inherits from ContextBoundObject, you have the ability to define rules and properties that apply to calls that cross the context boundary created for that object. What can you do with these rules and properties? Well, there's probably all kinds of interesting scenarios you can come up with. The most obvious are providing services such as tracing, security and validation for your classes. Implementing these services in the context of the object means the services do not impact the implementation of the object and the object does not impact the implementation of the services.
A ServicedComponent (Enterprise Services) is an example of a ContextBoundObject. All of those services that a ServicedComponent makes available are implemented seperately from your object. Likewise, you don't implement a lot of security/transaction/messaging code in your class. By inheriting ServicedComponents, these services become part of the context that your object is instantiated in.
The word for this type of seperation of responsibility is orthogonal, but I hate that word because I always have to grab a dictionary when I hear it. Encarta says orthoganal means “relating to or composed of right angles.“ That really clears it up, doesn't it? ;) Let's try a geek dictionary, wikipedia.com: “Orthogonality is a system design property which enables the making of complex designs feasible and compact. The aim of an orthogonal design is to achieve that operations within one of its components do not create nor propagate side-effects to other components. For example a car has orthogonal components and controls, e.g. accelerating the vehicle does not influence anything else but the components involved in the acceleration. It would be a non orthogonal design were for example the acceleration to influence the radio tunning, or the display of time.”
Imagine implementing security services without causing side-effects to the components that those security services apply to. Tracing, validation and other services could also be implemented in an orthogonal way, rather than sprinkling code with helper statements. What other services can you think of that could be created orthogonally from the rest of your application?
I like the option of using a ContextBoundObject because I can get some of the flexibility of services without the overhead and deployment cost of Enterprise Services. Since ServicedComponents are also ContextBoundObjects, there is a nice migration path as well. Those “aspects“ that you implement for your ContextBoundObject should still be usable if your objects begin inheriting from ServicedComponent.
Is this an architecture/design pattern that you've used in the past? What have been your experiences with it? Is it something you could see as useful in the future? I've got some code snippets if anyone is interested in me writing more about the ContextBoundObject class.