Business Object DAL design [closed]

Question

When designing business objects I have tried several different methods of writing the data access layer. Some have worked out better than others but I have always felt there must be a "better" way.

I would really just like to see the different ways people have handled the DAL in different situations and their opinon of how the technique worked or didn't work well.

Answer 1

I've relied heavily on Billy McCafferty's NHibernate Best Practices article / sample code for many Web / WinForms applications now. It's a wonderfully written article that will provide you with a good solid sample architecture -- in addition to teaching you basic NHibernate and TDD. He tries to give you an overview of his architecture and design decisions.

He creates a very elegant DAL using generic DataAccessObjects which you can extend for each domain object -- and its very loosely coupled to the BL using interfaces and a DAOFactory. I would recommend looking at the BasicSample first, especially if you haven't worked with NHibernate before.

Note, this article relies heavily on NHibernate, but I think the general approach it could be easily altered to suit other ORMs.

Answer 2

Unfortunately I don't think there is a "better way", it's too dependent on the specific situation as to what DAL approach you use. A great discussion of the "state of the art" is Patterns of Enterprise Application Architecture by Martin Fowler.

Chapter 10, Data Source Architectural Patterns specifically talks about most of the most commonly used patterns for business applications.

In general though, I've found using the simplest approach that meets the basic maintainability and adaptability requirements is the best choice.

For example on a recent project a simple "Row Data Gateway" was all I needed. (This was simply code generated classes for each relevant database table, including methods to perform the CRUD operations). No endless debates about ORM versus stored procs, it just worked, and did the required job well.