I can understand that developers might end up using your context as a dumping ground for all the data that they couldn’t be bothered to find a better place for. But then I’ve seen this happen with many other kinds of design. In fact I’ve gone to extreme lengths in the past to prevent this kind of ’subversion’ of my designs, all to no avail. What can I say - some developers are lazy, and don’t take the time to appreciate the spirit of a framework, before they crap all over it.

Either the contexts were compulsory, in which case perhaps a static constructor was necessary to preinitialise the root context, or your developers should have written their code to cope with the situation where there was no context available. Perhaps the use of an ambient context creates a reponsibility on the rest of the framework to be able to cope with its absence? For instance the TransactionScope class is not compulsory in most cases, and if it’s not present the database operations will still progress, just without an enclosing transaction.

For example; having the ability to embed their code in the framework, the developers of TransactionScope were also able to define a means to declaratively mandate the use of a transaction scope. Without such access I guess you’d be forced to use something like PostSharp or some AOP framework to add wrappers around your methods to enforce mandatory context policies. That’s already getting pretty complex, but if these contexts genuinely have a lot of data to carry around, and there really is a scoping concept in play, then it’s probably still preferable to dumping all that luggage into every method signature.

Cheers

Andrew

Giving a design pattern a name is probably the hardest part!

I noticed when researching this pattern that the .NET framework makes heavy use of the pattern, but does not provide any automated support for context flow. As a consequence I was forced to supply thread amagement functions in the ContrextManager, which I’m sure you’ll agree is a Kludge. I can’t recall (it’s been about 6-7 years since I was a java programmer) whether there was any sort of automated hook to allow you to do thread setup. If there is, you may be able to ignore the Contextmanager.Run method in favour of something less intrusive.

Please write (or link) back with any comments you have on improvements and/or flaws in the design I’ve provided. It’s only a first draft and surely not the perfect solution or description. If you can come up with improvements I’ll happily update the page.

Cheers

Andrew

However…I am not convinced it is a good idea. In my case, the context became a bit of a black-box. It was difficult to know how to properly populate one, and it made writing some code more difficult, because the programmers had to construct contexts when even one part of the code they wanted to call required it. It might have been better to pass more parameters around.

Yes, that might help. I’ll update the post soon…

Andrew