1

I'm working on an MVC application using C#/asp. The project is following an n-tier architecture style with a separate data layer, domain layer and presentation layer. My question is related to the use of models and entities in the different layers. Currently the project uses DTOs in the data layer and dapper to query the database, these get returned to the domain layer where they're mapped to more complex domain models, these are then returned to the presentation layer where they are mapped to view specific view models. Each layer has its own mapping classes to help keep separation of concerns.

Is having a different model/entity per layer the best practice here? I'm trying to improve my understand of what should and shouldn't be done when passing data between layers and I have tried to research this topic but I can't find a concrete answer as most examples show the entities in the Data layer being passed straight up to the presentation layer but that seems like tight coupling to me.

Thank you in advance for any help and I would be extremely appreciative of suggested books or blogs that would be beneficial to my understanding.

Improve this question

2 Answers 2

Reset to default
2

The combination of MVC and the tiered architecture lead naturally to such situations:

  • In MVC, the model manages all the domain objects and operations, including persistance and domain operations. The view corresponds to the output and the controller to the translation of user input into either commands for the view or commands/queries for the model.

  • In a typical layered architecture, the data layer flattens the model to fit into the database, the domain layer implements the model except the persisistence, and the presentation layer implements the user interface by combining view and the controller.
    The layered architecture tries to decouple the layers. Since each layer builds on the preceding one, you can't have the full domain object in the database layer already. This is why the DTO comes in.

So there is nothing bad in it. It's just the consequence of combining the two architectures.

As alternative, you may look at domain-centred architectures like hexagonal architecture, onion architecture or clean architecture. These put the domain objects at the core and prefer dependency injection for managing persistance instead of building on top of a database layer (e.g. with EF). This avoids the duplication of related data structures across the layers.

A look at Patterns of Enterprise Application Architecture gives a good view on the different architectural alternatives (the book is mainly with Java examples, but is definitively still worth reading).

Improve this answer
1
  • 1
    That makes sense! I had never considered that the structure of the project was because of the combination of MVC and the tiered architecture and your explanation of the DTOs used in the data layer to help build the domain objects makes perfect sense. Thank you for your answer and the resource links, I really appreciate it. I have been interested in learning domain-driven design as the projects at my work are being migrated to this type of architecture so this gives me the perfect excuse to get a head start on learning it.
    – AnabolicMike
    Commented Aug 3 at 18:27
2

Is having a different model/entity per layer the best practice here?

It's common, but no.

You can cleary save a lot of code if you map your datasets/readers directly to your Domain Models instead of having Entities.

And View Models are simpler if they are collections of Domain Models rather than completely new objects.

DTOs between a front end and an API can also be avoided by just using Domain Models.

Now, I think anyone can see the practical side of such an approach. But can it be backed up academically?

You would have to argue within a particular framework or practice. For instance I might say "repositories should return domain models" and then go into some theory from clean architecture. But it would be a complex argument to construct. I might have to convince you of a bunch of other stuff before we go onto DTOs

Secondly, do frameworks support this approach? Many will try to tightly couple to your objects with attributes or interfaces. If you want to avoid that you can be pushed into making DTOs.

I go with a practical argument on most things, if I can move the mapping code around and delete a few hundred DTOs that are basically the same as my Domain Models I do it and call it good practice because the code is simplified.

If I have some very OOP style Models with lots of methods, private data, calculated fields etc and I need to pass them over the wire, then I make DTOs

Improve this answer
1
  • Thank you for your detailed response it has really helped a lot. I wrote the question I was expecting a black and white one way is right and the other is wrong kind of answer but it appears much more nuanced, like most things in software development, and that the "right" solution is the one that fits the requirements of the project and not some pre-defined rule. This has made me realise I need to do some more research into the different architectural styles so I can better understand these nuances. Thank you again for your answer.
    – AnabolicMike
    Commented Aug 3 at 18:27

Your Answer

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

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