Define data access layer

Question

It seems that everybody knows you're supposed to have a clear distinction between the GUI, the business logic, and the data access. I recently talked to a programmer who bragged about always having a clean data access layer. I looked at this code, and it turns out his data access layer is just a small class wrapping a few SQL methods (like ExecuteNonQuery and ExecuteReader). It turns out that in his ASP.NET code behind pages, he has tons of SQL hard coded into the page_load and other events. But he swears he's using a data access layer.

So, I throw the question out. How would you define a data access layer?

Answer 1

What your colleague is talking about is not a DAL by most peoples reckoning. The DAL should encapsulate any calls to the database whether done by dynamic SQL, stored procs or an ORM with something like IRepository. Your web pages never should contain SQL or business logic or else it becomes maintenance nightmare.

Answer 2

A very simple example for .NET would be as follows.

If have two classes: SomePage (which is an ASP.NET Page) and DataService (which is a plain old C# class)

If SomePage always calls to DataService to read/write data then you have a Data Access layer. SomePage will contain no SQL or references to System.Data.SqlClient classes.

But SomePage can use DataSets or business objects that are passed from and to the DataService class.

Answer 3

I found this article about creating a DAL:

http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/

Answer 4

In addition to what the others have said, I usually consider it the place to abstract out how your data is being stored. A really good data access layer should allow you to swap out Oracle, SQL Server, Access, a flat text file, XML, or whatever you want, and doing so would be transparent to the other application layers. In other words, the contract between the data access layer and other layers should be defined in a database agnostic way.

Answer 5

I personally define the DAL as where the interactions between my application and the database exist. So I may have a Business Layer that interacts with the DAL to allow CRUD operations.

EG I may have a ModelClass.LoadAll() method that would interact with the DAL, which would fetch the data and the ModelClass would use that data in whatever way it needed.

I prefer to keep the DAL as light as possible, but some other people prefer the other way where the populating of the Model Data happens in the DAL.

Answer 6

A data access layer accesses data, and nothing else.

Answer 7

A "Black box" that holds your data. If it's user cares/can tell that there is a DB back there (aside from per consideration), it's not quite what I'm thinking of

Answer 8

I would love to share this design of data retriever (read-only) layer.

Keys for the architecture:

• The idea is to create an object which is almost singleton (explained below) that is to hold data that are retrieved with get-methods - below I call it the DRO (DataRetrieverObject).
• It should be easy for the client object to reach the DRO.
• It should be easy to maintain the classes.

The structure is based on a three-step construction.

1. Use a DataRetrieverFactory having (overloaded) static methods, one for each table you need. Use the overloading to match different kind of keys. The method will return a DRO.

2. The DataRetrieverFactory delegate the construction job to a second class <TableNameAndKey>DR that will create the actual DRO.

3. In the <TableNameAndKey>DR we have a static list of pointers to DRO's, loop the list in order to see if you already have a DRO with the specific key.

   3.1. If you find a DRO - check if it is ok (meaning:

   • it should not be "old",
   • it should belong to a session-run,
   • etc.)

   3.1.1. If the DRO is OK - then return the DRO.

   3.1.2. If the DRO is not OK then delete the object (and its pointer) and create a new DRO with data from the database. Store the pointer in the list.

   3.2. If there is not hit in the list of pointers, then we create a new DRO with data from the DB, and store the pointer into the static list.

Using this technique one may reuse the DRO depending on the need, however the class is not singleton since we are allowed to have plenty of instances of the class.