What to return from the DAL to BLL

Question

I currently have an application which consists of: User Interface (web page) BLL (Manager & Domain Objects) DAL (DataAccess class for each of my Domain Objects).

I u

Answer 1

To follow the intended model. the Data Access Layer (DAL) is responsible for retrieving and sending data from and to the data source.

The DAL must not care about any of the business entities your BLL is using as its only job is to retrieve data and return it in a neutral object. It must be neutral for generic reuability, otherwise you might as well not separate the layers as you are defiting its purpose.

Your Business Logic Layer (BLL) must not care how the DAL achieves retrieveing or writing data.

To communicate between the BLL and the DAL you must use neutral objects.

Your BLL passes an object's properties as individual paramters to the methods in the DAL. the parameters in the DAL are neutral using strings, int, bool, any other .NET objects which are neither specific to a version of the database you are communicating with nor are specific types only existing in your BLL.

The DAL will retrieve the data from where ever by what ever means and return a neutral data object to the caller. This for example could be a DataSet or DataTable or any other object NOT specific to a database type/version your are using. Hence DataSet and DataTable are objects within the System.Data namespace and not the System.Data.SQL,etc... namespace.

In essence: - BLL passes neutral types to the DAL (e.g.: string, int, bool, long,float, etc..) - DAL is responsible for converting those types to database specifci types if required before passing them on to the data source DAL returns neutral data types to the BLL (e.g.: DataSet, DataTable,etc..) - BLL is responsible for using the content of those neutral data types to create, populate and return specifci Business Entities

Your BLL must reference your DAL. that's it.

You can off course completly ignore this model and hack about as many suggested previously using IBOOK,etc... but than your are not using the intended model and might as well throw it all into a single assembly as you won't be able to maintain it independantly anyway.