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.