One Data Access Layer serving multiple Business Layers? or not?

Question

I have (or will have) one DAL containing my data access methods of our ERP system.

Business-wise there are contexts that will use this DAL. Examples are: Barcode applications, custom sales picking applications,purchase order applications.

I am thinking instead of creating one DLL for my business layer to break it down to these major areas, thus making them communicate with DAL in-dependably. This will help reduce bloat on my finished apps

This is my first question, the second is that Data Acess objects that are common between the Business layers should they reside in a separate project in order to be accessible by all BLs?

Lastly , these data access objects are uselul to DAL also since many methods return lists of these objects to either Business Layer or directly to Presentation (not common but will happen). Should they refer to the same common class that has the DAO's?

Answer 1

I think that the answer to your second question is fairly clear; the DAL should have its own project.

As to the first, it really depends on how much commonality there is vetween the different application needs. You also need to consider whether spilitting into several BLL DLLs will increase the complexity for maintenance of the Business logic.

I would urge caution on your last item of accessing the DAL as well as the BLL from the same UI. This means that you could have dependancy on both. It may be better to put simple methods into the BLL which just call the DAL functionality and return the answer so that everything goes from the UI to the BLL to the DAL.

Of course, with all of these things, you need to think about which answers will suit your applications and development methodology the best.

Answer 2

You can have domain objects that both your DAO and BL can use. The domain object should be extremely dumb, all it should be is a representation of a given entity.

Example:

Bl.Get-employee -->Return Domain Object Employee

BL.Get-Employee method calls the DAO that translates your data mining into a domain object, in this case an Employee domain object.

Bl.Get-employee>>Calls DOA.Get-employee. All database operations should be handled by your DAO.

In a scenario where you have business logic your code may look like this.

Employee Bl.ProcessRecord(EmployeeDomain Employee)
{
    //Do some logic....
    //Perhaps interact with other DAO operations
    //Have some business logic operations ETC
    Persist your changes to the database
    Employee = DAO.Save-employee(Employee)
    return Employee;
}