3

I have a question about architecture in .NET.

My architecture is like this :

Projet :
- DAL (Data Acces Layer)
- BLL (Business Logic Layer)
- DTO (Data Transfer Object)
- IHM (man/machine interface)

DAL : Acces to the database (CRUD) It reference DTO
BLL : Logic Layer do all logic process and make the connection between IHM and DAL. This layer reference DAL and DTO
IHM : Presentation Layer (asp MVC) this layer has a reference on BLL and DTO DTO : I put EDMX (Entity Data Model) in this layer (cross cutting)

My question is about the EDMX. I put it in DTO layer in order to make accessible the object to all other layer. In my IHM layer I map DTO's object with ViewModel to send to the view only the field needed

I see in other project they put the EDMX in DAL but they create object in each layer and map them. It's unpleasing and it's code duplication.

Is it bad to put EDMX in DTO and why ?

Regards

Improve this question
2
  • Please format your question and write out any acronyms at least once, explaining each layer's responsibilities in a few words. A layer that can be accessed by all other layers (considering you have more than two) is nor really a layer, is it?
    – Martin Maat
    Jan 6, 2019 at 14:54
  • Why the business has to deal with 2 different data models? (DTO and EDM). Why do you think DTOs are needed in your architecture? Why all layers should have access to the EDM?
    – Laiv
    Jan 7, 2019 at 8:24

1 Answer 1

Reset to default
2

Here's how I would do it:

I would put the EDMX in the DAL, since Entity Framework is an ORM (Object Relational Mapper), and that is a data access concern. The classes it generates are laden with EF-specific functionality that shouldn't leak into the rest the application.

I would also repurpose the "DTO" layer into something more like the "Business Object" layer, which will have your core business objects. The DAL would return these business objects, not the auto-generated EF-specific classes that the EDMX provides.

Finally, your IHM layer would be where either the DTOs (for machine interfacing) or ViewModels (for human UI) would be defined. These classes don't have any meaning anywhere else.

Improve this answer
2
  • Hi, I agree the DTO should be rename as Business Object. So if you let the EDMX in DAL you'll create a lot of POCO in your Business Object and you 'll recreate the navigation property between POCO ? Imagine you'll change the type of column in your DB (varchar to number) your EDMX will be regenerate so the modification is immediate but if we had created POCO we will need to change the type of property in our classes. Best Regards
    – vincent benazet
    Jan 8, 2019 at 9:01
  • You'll create a lot of business objects in your Business Object layer, reflecting a normal object-oriented design. There are no such thing as "navigation properties" in object oriented design... that's an EF thing and is a database-specific concept (and which is why it belongs in your data layer). If you need a new property in a business object, you create it there, and then propagate it the EDMX if you need to persist it to the database. That's how domain design should work. If all you need is forms-over-data, then most of this design thinking is already unnecessary.
    – Eric King
    Jan 8, 2019 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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