I am thinking on how to structure a project. I wonder if it is a good practice to use different entity classes between the BL and DAL in order to decouple these layers.

I have worked on projects where entity classes where in a separated project/package. Then BL and DAL used the same entities.

But I can imagine that a better approach is to define an entity class for every layer and its assembly. What are the objective pros and cons of such approach ?

  • 1
    Welcome. Unfortunately your question is not very clear. Is it about how to structure your projects to share entities ? Is is about using different entities ? and what do you mean with "ist assembler" ? Could you rephrase your question to clarify ?
    – Christophe
    Sep 22 '18 at 11:35
  • I have edited my initial question Sep 22 '18 at 16:50
  • separating them is a pain in the ass, using 1 entity as both save you from mapping burden
    – Konrad
    Sep 22 '18 at 18:13
  • if by business logic entities you mean classes with methods (encapsulation)..., otherwise just put all your logic in some separate place like service classes or something else
    – Konrad
    Sep 22 '18 at 18:14
  • in the end it doesn't matter, do what works first and then if you find that you really need the separation just do it later
    – Konrad
    Sep 22 '18 at 18:15

BL, entities and DAL

The purpose of the BL is to implement the domain logic that work with domain entities. The definition of these entities is business driven.

The purpose of the DAL is then to organise the persistence of the domain entities. The idea is to hide from the upper layers the ugly details of the data access and the database. If it's well done, you could change the database under the surface, and still leave the higher layers unchanged.

Unsurprisingly, the domain entities are shared across both layers: BL needs them to carry out domain activities, but DAL needs them to organise their persistence.

Decouple BL and DAL ?

Decoupling components is generally a very good idea. However, layers are not independent components. Layers are a logical groupings of related classes.

If fact , you could as well redraw your layer diagram, and imagine a layer between BL and DAL that contains the Entities. And all the sudden, the layers would appear clean and decoupled.

What are the alternatives ?

You propose as alternative to use two different kind of entities in the different layers. So you would have proper domain entities in the BL. And you would have intermediate data access entities in the DAL.

Now imagine you'd implement this perfect scheme. How would you then make the link between the BL entity and the DAL entity ? Somehow these would have to know each other to synchronize data. So you would end up having a strong coupling between the layers anyway. It's just that it would be less obvious.

  • I would need "only" to write a mapper/assembler class in the BL layer. And if a new DAL comes, I have to write another mapper for the entity of the new DAL. But the BL will works always with its entities. Open/Close principle, right? Sep 23 '18 at 7:42

Define entities in a class and use the same entity in BL and DAL. this design save your time and bug that came from changing entities time to time.

  • 1
    But if a change comes in the database, I have to change the entities of the DAL of course but I also have to adapt my BL because of this change in the database. Sep 22 '18 at 16:49

If the project is straight forward and using single data source, it makes sense to use same entity classes where business logic and data access layer use the same entity classes. If you are dealing with multiple data sources, and business logic is dealing with multiple data sources and handling lots of validation, and data transfer; you can use separate objects i.e. data transfer objects for business layer. That gives flexibility to give one simple DTO to presentation layer in a single call.

Not the answer you're looking for? Browse other questions tagged or ask your own question.