Mark Mintoff My superpower is common sense

6Mar/117

Connection Class -and- Data Access Base

Seeing as I have blogged here and here about Data Access, I thought I ought to resume my little trend and push forward towards a good Connection Class and Data Access Base design. My connection class design is meant to integrate with my DataReader class, and goes further to simplify everything in connections. The Data Access Base inherits from the Connection Class, further simplifying everything through object inheritance.

For the purposes of this blog, I have simplified the Connection Class ever so slightly. Basically, since I work from more than one computer, I keep a value in the web.config, indicating which connection string I want to use. This blog post will assume there's only one connection string to utilize.

What is being done here is fully automated management of transactions, utilization of my reader class and simplified connection handling. This goes well in conjunction with the Data Access Base as follows:

These two interfaces provide a basic cascading inheritance model for the DataAccessBase class, which allow for better generic handling (collections, where clauses, etc) when utilizing DataAccessBase classes.

DataAccessBase will inherit from IDataAccessBase<T> specifying that T must be an IEntityBase. Now let's suppose we wanted a collection of different DataAccessBase<T>. This cannot be achieved since we cannot specify T for each one in the collection. Hence, we can create a collection of IDataAccessBase, which is allowed.

As you can see, there is a try-catch-finally block, along with OpenConnection and CloseConnection in each public method surrounding the protected abstract methods. This means that when a Data Access Component inherits from the DataAccessBase, the methods will be infinitely simpler as there will be no need for connection handling or try-catch-finally blocks. This simplifies a lot for the basic methods of communicating with the database; Get, GetAll, Set and Delete.

Now let's take a look at an example of a Data Access Component which inherits from DataAccessBase;

As can be seen, this simplifies the data access significantly, reducing development time and implementation cost greatly.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Comments (7) Trackbacks (0)
  1. I might be wrong, but I’m noticing that for every table in your DB, you have to create two classes, the DAC_MyFile and MyFile classes. DAC_MyFile that will implement the DataAccessBase<T> class and calls the Get, Set, Delete, stored procedures and the MyFile class that will have the properties and methods to be used from the project.
    Isn’t there a cleaner way to do that, where you have one class for each table? Or did I miss something?
    (I haven’t worked with Generic types before so I might be wrong. Excuse my stupidity in that case)

    • You are correct in the sense that; yes there will be two classes per table for this layer. In actual fact, in my own implementations I also use a caching method, which results in 3 classes per table. I do however use a lot of snippets and templates which make the job easier. I do not understand what you mean by “cleaner”. A higher level of abstraction results in more classes as opposed to less.

      I think what you are asking for is a quick-and-dirty solution; of which I personally do not approve. Putting the database access logic inside the entity class would increase the footprint of the class in terms of memory. Which would make most sense:

      1. A million entities with database logic to self-update, self-delete, self-insert, self-load?
      2. A million entities which point to an external factory class to do all the necessary database work?
  2. Been trying to reply but it wasn’t working. Anyway, I agree. Didn’t think of it that way. Thanks for the advice and keep up the good work ;)

  3. Hi Mark,
    Hope you’ve been well. You think you can give an example of these classes with multiple connections to different databases and using transactions?
    I’ve been using your model for any new projects that I’ve been doing and I found it really good. I love it, but I don’t know how to go about it when I need to use two (or more) different databases with this model. Even when it comes to transactions; do I create an instance of the Connection class so I can pass the connection I want and transaction to the constructor or is it meant to be used differently?
    You think you can help me out? I’d really appreciate it.
    Thanks ;)


Cancel reply

No trackbacks yet.