Description of DAL

All code that is specific to the underlying data source – such as creating a connection to the database, issuing SELECT, INSERT, UPDATE, and DELETE commands, and so on – should be located in the DAL.

[DAL] methods could simply return a DataSet or DataReader populated by the database query, but ideally these results should be returned using strongly-typed objects. A strongly-typed object is one whose schema is rigidly defined at compile time, whereas the opposite, a loosely-typed object, is one whose schema is not known until runtime.

http://msdn.microsoft.com/en-us/library/aa581776.aspx

Thus, your business tier contains logic for retrieving persistent data from the data-tier and placing it into business objects and, conversely, logic that persists data from business objects into the data tier. This is called data access logic.

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

The DAL should have no knowledge at all about the Business Logic Layer. It should, in theory, be able to be called from any client. For example, what if you wanted to seperate the DAL from the application and deploy it as a seperate service exposing itself via WCF?
As mentioned, the DAL operations, e.g. SaveNewsItem should be be accessed by the BO via interfaces, perhaps via dependency injection/IoC.

ng5000 H
2009-01-19 16:18:31

Yes, I agree - it is better that the DAL does not know about the BLL. Instead the DAL should have some sort of abstraction so that the BLL can construct its entites from 'raw data' ie DAOs (or XML or a map of key/value pairs for example). These factories are better separated from the domain logic

Tom Carter

 http://www.techques.com/question/1-458098/Business-Logic-Layer-and-Data-Access-layer:-circular-dependency