How to organize Data Access Layer (DAL) in ASP.NET

Question

I have an ASP.NET Web Forms application developed in C#.

I would like to give structure my application by separating the DAL tasks from the code behind.

I created a class in App_Code, DBUtilities that takes care of the communication with the database, in order not to have duplicated code all along the application. The class has methods to get datatables, scalar values, etc... and they accept as parameters the connection string name and the query command as string.

The problem is that I have still all the queries' commands in my code behind. Many of them are duplicated all around the pages and this cause maintanance problems.

I was wondering if it is a good practice to create a (static) class QueryRepository that contains many string properties and associate to each of them a specific query command. Everytime I want to execute the query command MyCommand I pass to the DBUtilities class the QueryRepository.MyCommand property instaed of the string. Morevoer if I need to change a query command I do it just on the QueryRepository class.

Is it a good way to organize my DAL?

Answer 1

For ASP.NET web forms implementing Model-View-Presenter (MVP) pattern can be one good approach to separate your logic and database queries from the UI code behind. You have to write a Presenter class that has a generic reference to a view interface and has a model in it which has database queries, logic etc. The presenter will call functions of the generic view interface in all its functions. Then you can write the actual ASP.net view. In the view you instantiates and reference this presenter and while instantiating the presenter you inject the self object i.e the ASP view itself (using "this" keyword) to the Presenter. You can design proper inheritance for your presenter classes based on your need so that they are reusabe and can be unit tested.

Addition in response to CiccioMiami's query:

Here are couple of links to start

http://www.codeproject.com/KB/aspnet/AspNet_MVP.aspx

http://wiki.asp.net/page.aspx/340/mvp-pattern/

The difference in the MVC and MVP pattern is explained here: http://www.codeproject.com/KB/architecture/DotNetMVPFramework_Part1.aspx

To add to this, for ASP.net Web form architecture, the Requests are tightly coupled with the page life cycle. You have series of page life cycle events and developers write code in each of these events. Thus the business logic becomes tightly coupled to the UI view. Over the period of time this is not a good situation for code maintainability and unit testing. Unit testing is difficult in ASP.net web forms as it is difficult to simulate the requests and page life cycle events. In MVC the requests first comes to a controller. The controller uses the model for business logic and passes the model to view. The view renders using the model data and is returned back as the response to the user. The controller has greater control on the work-flow. You can test the model, DTO transfers etc. as you could do in a standalone app. With web forms there is no controller the request directly comes to ASP.net page which is a view. There is nothing much user can do. Good that Microsoft realized this problem and we have ASP.net MVC. The MVP pattern for ASP.net webforms will solve the code separation problem to some extent. The best option is to use ASP.net MVC if not then you can use MVP with Webforms.

Answer 2

Long term answer: I can really recommend you read Professional Enterprise .NET

The ASP.NET website has a good example of the repository pattern which is worth looking at.

I'm no expert, but if your DAL can conform to a best-practise patterns it's more likely to be a good way for it to be organised.

I'm struggling to follow your DAL design without a concrete example, so not sure I can help there.

Answer 3

Few steps to follow:

It is good practice to separate the DAL, BLL code from presentation(UI) layer, however to go accordingly below steps would be helpful.

1. Create DTO (Data Transfer Object) or Entity
2. Fill the DTO/Entity from presentation layer
3. Pass it to a public method to your BLL layer and validate Business Logic
4. Then pass the DTO/Entity to DAL layer (at DAL layer, create a method which return Command, then put your CommandText, CommandType and then Set value, data type and size to all the parameters, also create execute method which get Command and return results).
5. Finally, execute your desired execute method ( created at DAL layer)