For this edition of the development log, I thought I would discuss the data access layer for ConTrak Systems. This theory can easily be applied to a variety of ASP .Net implementations, and is not even limited to the .Net platform.
From the ASP .Net web forms and web control pages, there are normally four layers of data access. In order from which is called first, I have the managers, data, DBAccess class, and the DBA classes. I do this for a variety of reasons, explained below:
Manager Classes: All requests for data from web form pages pass through this layer. These classes are grouped via topic, such as the auction and registration. A manager class’s primary job is to call the data class and perform any additional formatting or combining necessary before handing the data to the web form pages for data binding or other work. One such example is converting a multidimensional array into an array of List Items for binding to drop-down list boxes. Manager classes some times handle security when I feel all the security could not be done in the web form page.
Data Classes: Though some objects in ConTrak are smart enough to update themselves, all requests to update data will flow through these classes. As with the manager classes, these classes are also subject-oriented. The data classes contain the SQL code necessary to update the database. All data classes extend the DBAccess class and use the doSQLQuery and doSQLCommand methods, accessible through this inheritance, to update the database. I do not use parameters for the queries; rather, I write the query or command out, complete with the data. Some times, I use a DBADataSet class to return a customized data set (containing a save method that triggers the data set to update to the database) containing information the data classes need, but I only use this for mass updates and specific occurrences. Data rows returned from doSQLQuery are never updated (used as read-only) and all database insert, update, and delete commands come through doSQLCommand. As you can imagine, the doSQLCommand method is overloaded to accept arrays and array lists so the database connection does not have to be closed and re-opened for each command. Class names at this level follow a naming convention, such as “RegDBA” and “ArtShowDBA”. This is not to be confused with the lowest-level DBA classes!
DBAccess: This is the heart of data access. DBAccess is never instantiated, but inherited by all data classes. When it hits this point, I need not write any new code. DBAccess extends either one of two classes, OLEDBDBA or ODBCDBA. These two classes are discussed below in the “DBA classes” section. DBAccess mostly acts as a switchboard for how I wish data access to proceed. However, DBAccess contains some methods, like user information access and other items I wish to share across my data classes.
DBA Classes: These classes are the lowest of the low in ConTrak’s call stack. These classes are exclusively used for the DBAccess inheritance relationship and are never instantiated. The only two class files at this layer are ODBCDBA and OLEDBDBA. I use DSN exclusively on my development machines (usually “Sager8790”, but I sometimes use “MAGE” for things), but am usually forced to switch to OLE for web hosting environments. These two classes are in charge of opening the database and issuing CRUD commands via the overloaded doSQLCommand and doSQLQuery methods.
--------------------
I hope interested parties learned something from ConTrak’s data call behaviors and the coding technique I developed. ConTrak has been a very beneficial learning experience for me as well. It’s a shame ConTrak, the Financial Game, and my other development projects are still not enough to get me in the door for employment… I wonder what I will have to do to get a job, now?
