IDisposable
Bill Wagner's article on IDisposable is interesting. From all objects that implement this interface, my favorite is always database access objects (like SqlConnection). For a long time, I've been discussing with our brilliant architect Ed Jezierski about this.
Why should a developer building "business solutions" ever care about closing a connection to a database, or even opening it?
The "using" statement is one step forward, but not enough in my opinion. In the same way you need to remember closing a connection, you need to remember using "using".
Also, the "connection string" is usually a place where all sort of really low level parameters are declared (like pooling options, timeouts, etc.). if you think about it, all these are really very important aspects of the application that are usually essential for the stability, robustness and performance of not just one module, but the whole application.
Forgeting to close connections to a database is probably one of the silliest yet most frequent sources of problems, at least in my experience working in IT and helping customers build (and repair) business solutions.
So the question is: should we fire all developers who forget to close connections or should we build or design something that would take care of the problem effectively?
I believe this falls into the broader category of "concerns" that don't belong to the business solution level. In my opinion, a developer (again, those building business components) should never care about dealing with this.
Of course somoene has to take care of it, but I insist not the developer. The underlying architecture of the solution should provision all this and act defensively in case things don't happen as expected.
To be continued...
