Data Layer Best Practices

Question

I am in the middle of a \"discussion\" with a colleague about the best way to implement the data layer in a new application.

One viewpoint is that the data layer should

Answer 1

You can have both. Let data layer not know of your bussiness objects and make it capable of working with more than one type of data sources. If you supply a common interface (or an abstract class) for interacting with data, you can have different implementations for each type of data source. Factory pattern goes well here.

Answer 2

It really depends on your view of the world - I used to be in the uncoupled camp. The DAL was only there to supply data to the BAL - end of story.

With emerging technologies such as Linq to SQL and Entity Framework becoming a bit more popular, then the line between DAL and BAL have been blurred a bit. In L2S especially your DAL is quite tightly coupled to the Business objects as the object model has a 1-1 mapping to your database field.

Like anything in software development there is no right or wrong answer. You need to understand your requirements and future requirments and work from there. I would no more use a Ferrari on the Dakhar rally as I would a Range Rover on a track day.

Answer 3

Jeffrey Palermo wrote a good post about this. He called it Onion Architecture.

Answer 4

One trick I've found handy is to have my data layer be "collection agnostic". That is, whenever I want to return a list of objects from my data layer, I get the caller to pass in the list. So instead of this:

public IList<Foo> GetFoosById(int id) { ... }

I do this:

public void GetFoosById(IList<Foo> foos, int id) { ... }

This lets me pass in a plain old List if that's all I need, or a more intelligent implementation of IList<T> (like ObservableCollection<T>) if I plan to bind to it from the UI. This technique also lets me return stuff from the method like a ValidationResult containing an error message if one occurred.

This still means that my data layer knows about my object definitions, but it gives me one extra degree of flexibility.

Answer 5

An excellent book I have, which covers this topic, is Data Access Patterns, by Clifton Nock. It has got many good explanations and good ideas on how to decouple your business layer from the persistence layer. You really should give it a try. It's one of my favorite books.

Answer 6

In applications wherein we use NHibernate, the answer becomes "somewhere in between", in that, while the XML mapping definitions (they specify which table belongs to which object and which columns belong to which field, etc) are clearly in the business object tier.

They are passed to a generic data session manager which is not aware of any of the business objects; the only requirement is that the business objects passed to it for CRUD have to have a mapping file.