Always Get Better

When we learn how to open and use a database connection with ASP.NET, as with any other programming concept in any other programming language, the simplified version used to explain what’s going on is not truly representative of the quality professional code we will one day be expected to write.

Opening and Closing Connections

Case in point: managing of sql database connection resources. How many of us learned to write something like this:

Sure it’s easy to follow, but if you deploy that on a moderately busy server you are going to make your client very unhappy.

Dispose Resources

SQLConnection and SQLCommand objects reference unmanaged resources, meaning the C# garbage collector has no framework knowledge about your object. Since these classes both implement the disposable interface it is important to call the Dispose() method in order to correctly free your application’s used memory.

So our code gets updated to look like this:

Trap for Errors

What happens if there’s a problem, and your code fails to complete? If your application crashes before your objects are disposed, you are left with the same effect as if you had never disposed your objects at all!

Fortunately, C# includes the try … finally reserved words. If anything within the try { } block fails, the finally { } still executes. We can easily apply this to our program code:

For my own part, I prefer the using keyword. We can include a using call anywhere we would ordinarily use a disposal object. When the code is compiled, it behaves the same as try … catch, but leaves our program code much more readable.

Even better, we don’t even have to bother calling Dispose() because it does it for us!

Slick.

Open Late, Close Early (like a bank)

There is one more thing I would add to this. Creating objects in memory takes time. Although it happens in fractions of a second too fast to be detectable by us, it’s important not to waste processing time wherever possible.

Whenever we Open() a database connection, we expect to use the database right away. If we then create an SqlCommand, we’re wasting the open connection’s time. It’s as if we pick up the phone and listen to the dial tone while we then flip through the white pages looking for the number we want to call.

Let’s change our example code so we will now Open() at the last possible opportunity, and Close() right away when we’ve made our call:

In the end, the program code we wrote is very similar to the newbie code we started with. However, we’re now protecting our system from memory leaks, and we’re protecting our database from wasted clock cycles. Our code is easy to read and stable.

[This is a followup to: Maintaining SQL Connections in ASP.NET]

Here’s a geeky party trick:

Abstract classes in Java cannot be instantiated. Here we’re going to consider ways in which a button can be programmed within a JPanel. ActionListener is used to react to the button event, but ActionLister is an interface (pure abstract class) so in order to use it you have to derive a class from it and implement actionPerformed.

For example, you can’t do this:

You have to do this:

However, this code is valid:

What’s going on? It would appear that we are instantiating a new ActionListener and giving it an actionPerformed() method. We’ve succeeded in giving our button a listener without first creating a class to handle the event.

Anonymous Inner Classes

Of course we aren’t really instantiating ActionListener - it was a trick. What this does is create an anonymous inner class only in this part of our code. Check it out - when you compile your code, javac will create extra class files for our ActionListener.

For one-off buttons, using anonymous inner classes is an excellent way of reducing code bloat and improving the readability of your programs. There are drawbacks of course, which I’ll go into detail in another article, another day.