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...

Comments (5)
  1. Uwe Keim says:

    Yes, I totally agree!

  2. Paul Wilson says:

    A good code-gen framework or OR Mapper will handle this automatically for the developer.

  3. Sahil Malik says:

    A simple data access layer can ensure connections are always closed eventually. Thats pretty much all u gotta do !!

  4. "simple data layer"... says:

    The code gen approach may help, closing connections. In any case it is an underlying framework. Which is fine.

  5. Disagree w Sahil says:

    If it were a "simple" data access layer, then why people forget? Because they don’t use one? In either case, the decission to use a DAL is part of using a framework: understood as a way of standardizing development

Comments are closed.

Skip to main content