views:

622

answers:

7

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?

A: 

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

BCS
+1  A: 

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.

KiwiBastard
To me the DAL is just that a place that does my CRUD and connects to the DB only
Terry
+6  A: 

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.

Craig
+1 for most of this. Dynamic SQL, however, is often an indication of a poorly designed access layer.
S.Lott
+1  A: 

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.

rally25rs
+2  A: 

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.

tyndall
A: 

A data access layer accesses data, and nothing else.

IrishChieftain
A: 

I found this article about creating a DAL:

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

Terry