The Data Access Layer or DAL is a Microsoft good practices method implored by TheBeerHouse program. With a DAL the UI layer of applications have one place to go to access data. DALs allow for better object oriented coding.
Traditionally application code accessed databases with in the application code that also contained the GUI logic. This was fine if your system wasn’t planning on using any other databases and the code was flawless, accounting for all conditions. As that is a tall order to meet this made upgrading to different databases or changing data logic or code logic difficult to maintain which made the application more vulnerable. With a DAL you keep the access to and from the database as separate from the other parts of application design such as GUI or workflow logic.
The bulk of the TheBeerHouse is retained in HoneyCMS.
The TheBeerHouse DAL uses a Provider that allows indirect access to the database for the UI layer of the application. Each application feature(module) has code files specific to their logic within the application. This is good because no UI form has direct access to the raw store and we can add more security and validity check when needing data from the end user, before adding to the raw store. A rough representation of the flow is as followed:
DB <==> DAL <==> UI
The DAL contains several code files.
First there are two base files; DataAccess.cs and SiteProvider.cs. All feature or module base Provider inherits this class. the DataAccess class contains properties and methods dealing with caching, returning data set bas on given stored procedure. This as well as each class file will be detailed in their own post. The SiteProvider base file contain read only properties that return instances of an application module.
Next are the files specific to an application feature or module. Each module of the application has its own sets of files. The DAL contains an SQL Provider specific to the data of that module, a Details class that contain strongly typed properties, and a Provider class that serves as the data provider for that module.
Lastly, there are supporting class files in the DAL for some modules. For example, the Articles module uses catalogs and commenting support features.
Take the Articles feature for example, that module’s DAL files would be:
../DAL/SqlClient/SqlArticlesProvider.cs - Serves as a database provider for the Articles feature. It directly connects to the database, in this case MSSQL using ADO.NET. For MySQL an adaptor to take care of the conversion of data types, query language quirks and some .NET based quirks can be added. The MySQL website contains code files for the adaptor, which requires hardly any tweaks. HoneyCMS plans to implement Linq, its the future for data access because one language handles all types of data objects which you can perform queries upon, you are not limited to using a separate query engine for internal databases, external databases, app objects, xml, even open doc objects. It works because everything is an object and the engine takes the proprietariness out.
../DAL/ArticlesDetails.cs – Contains initialized and typed properties related to Articles. The Provider takes this class and uses it as an abstract list of type ArticlesDetails. This wraps or encapsulates the ArticlesDetails properties within the Provider preventing multiple instances clashes.
../DAL/ArticlesProvider.cs - Serves as Data Provider for the Articles feature to the GUI.
../DAL/CategoriesDetails.cs - Serves as a support class to add the category support feature to the Articles Provider.
../DAL/CommentDetails.cs - Serves as a support class to add the comments support feature to the Articles Provider.
Presently the features or modules that have their DAL files are: Articles, Forums, Polls, Stores, and Newsletter.
The support classes are: CategoriesDetails, CommentDetails, DepartmentDetails, OrderDetails, OrderItemDetails, PollOptionDetails, PostDetails, ProductDetails, ShippingMethodDetails,
Conclusion
The Data Access Layer serves as a best practices data logic model for application. In it the application data logic is separate from the applications other logic. Compared to inline data logic the resulting code is cleaner and more modular thereby making it easier to maintain and secure.
Our application’s DAL uses Providers for each application level to access the database. The Provider uses a combination of a Details class(strongly typed properties list template, List<T>), SQL Provider class(contains actual methods and properties to and from the database), and support classes to provide access to and from the database tables and stored procedures for adding, editing and deleting, sorting and or the summation of records.
The next posting will delve into the each file that makes up the DAL, beginning with the base code files then moving on the support code files and finally ending the the code files for each applications feature’s DAL.
Posts
