1

Let's say we have an application with a DAL, business layer, and presentation layer, we do dependency Inversion, and we place the database repository interfaces at the business layer.

At the data layer we use EF for database access. Who owns the entities? The business layer or the DAL?

I mean at the business layer we should already know about the entities, however the entities are generated by the data access layer. I think lower level modules should not know about higher level modules. I am really confused.

Improve this question
2
  • The code that generates the object is not part of the model. Think of it as the programmer that knows a lot about multiple layers but does not participate once the system is operational. So you cannot say your DAL generates your entities. It does not, a generator that reads the database structure does.. Commented Dec 28, 2016 at 11:41
  • Thank you Martin. Did you mean that entities generated by EF do not belong necessarily to the DAL? it is a shortcut to create the base for our model in business logic? And coincidentally the 'base models' are the same as the 'table-specific classes'? Commented Dec 28, 2016 at 13:39

1 Answer 1

Reset to default
1

Your "domain" knows about the entities (I'm using "domain" in a broad sense here)

The business layer is part of your domain. Most of the times the DAL is also part of the domain although not from what the implementation is concerned (i.e. you have a DAL interface that's part of the domain, it's that part of your domain from where you retrieve and persist your entities; if you use EF or something else to actually do it, it's not important).

Your entities usually span your entire application. You have bussines rules and behaviours but those rules work with your entities. Those entities also reach the user in the presentation and in their knowledge of the domain (i.e. your "domain" actually models the real business domain).

Yes, lower levels should have no knowledge of the upper levels, but your entities are not owned by the upper levels, they are (most of the times) cross cutting your entire application.

Improve this answer
3
  • Thanks Bogdan. I know that many times entities are extracted to a separate project and are reused across all the solution. I was rather interested on how to apply DI when connecting the Business Layer and Data Access Layer without sharing EF Generated entities. EF Generated entities can be regenerated, so even if we use partial classes, some things can disappear/appear. Commented Dec 28, 2016 at 14:00
  • I do not really see other solution if I want an abstract interface for the DAL, than to share the business models with a a 'mapping' layer, that acts as an adapter between DAL and Business Layer mapping from class-specific entities to model. Do you guys agree or have a better solution? Commented Dec 28, 2016 at 14:12
  • @Icebreaker, your entities should be POCOs. With EF you then just create instances of these from rows in tables. Sure, sometimes new fields are added or removed, but even if you had separate entities at the busines layer, you would still need to adapt those in the mapping layer to account for the new or missing fields in the DAL. I've seen solutions where each layer had its own entities and sandwitched in between there were mapping layers. You can go that way too, but most of the times you end up with a 1:1 maping that just adds duplication, maintenance work, and increases the room for bugs Commented Dec 28, 2016 at 14:24

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.