Is it reasonable to wrap a domain's BLL into it's own Class Library, and how would I set it up?

Question

I have heard of putting your DAL into a Class Library loads of times. It makes sense, and I want to do it so that I can reduce code duplication across applications. I have decided to use Entity Framework to build that DAL.

From what I understand about N-tiered applications, however, is that the DAL is really just going to expose POCO Classes, which I am going to treat like DTO's. To make that Easy, my DAL.dll is going to expose classes like EmployeeDto and methods like GetEmployeeDtoByID(int ID) just to make it clear that this layer does not produce final domain models.

But what If I want a reusable DLL that produces finalized domain models? It sure would be nice to be able to create a new project, add the CompanyBLL.dll reference, and start calling GetAllEmployees knowing that the Classes exposed here are true representations of Domain Models for that Object. Essentially each project I make just becomes a new Presentation Layer for different tools that are needed.

I know that these are personal choices that I should make as I start deploying N-tiered applications, but Is that a reasonable goal? If so, Do I make the DAL.dll, and only ever really reference it as I build my BLL Class Library? would it just make more sense to combine them into one single Class Library?

I'm just not sure if I'm crazy for not wanting to rebuild my Business Logic for each application that I make, and if this is the correct way to do it.

Answer 1

I would recommend this architecture.

Presentation -> BLL -> Repository -> EF -> Db

Your repository returns collections of your entities that EF is responsible for.

The responsibility of your repository is to perform CRUD operations. Internally it uses EF but your BLL or presentation need not know about this.