I am learning about DDD and I would like to say what is the correct way to implement DTO using DDD principles ?
In my onion architecture I implement a first DTO definition in presentation layer to map datas between RabbitMQViewModel(presentation layer) and RabbitMQModelsResultDTO (application layer).
And I implement a second DTO definition between application layer (RabbitMQModelsResultDTO) and domain layer (entity LogRabbitMQ).
However, I am not sure if it's a good way to implement two DTO definition ?
Light description of my DTO definition in
presentation layer :
CreateMap<RabbitMQViewModel, RabbitMQModelsResultDTO>().ReverseMap();
and application layer :
CreateMap<Domain.Entities.LogRabbitMQ, RabbitMQModelsDTO>().ReverseMap();
It's a screen of my project architecture :
Translating presentation object (RabbitMQViewModel) into application object (RabbitMQModelsResultDTO) then application object into domain object (LogRabbitMQ) is considered to be a good practice in the DDD world.
However, it is pointless to make anemic, flat translations: it would be much easier to use the same object through all three layers (in which case DDD becomes irrelevant).
Here is how it can be done in the DDD way:
Application object reflects domain context properties, namely value objects, into which presentation object's primitives are translated.
Domain object is a "smart" object, implemented with all OOP goodies in order to keep it consistent all the time, and this object is being constructed using application object's properties.
As for the term "DTO", it should be used primarily for presentation object. It is less appropriate to use it in the context of application/domain objects, which are considered to be business objects.
Related
I'm currently following an IT study, and we're asked to use interfaces and DTO's in a multi-layered ASP.Net Core MVC consisting of Presentation, Logic/Business, and Data Access, using dependency inversion so that both the presentation and DAL have references to the logic layer. In between the Logic and DAL, we have to use DTO's and Interfaces. I understand the concepts of both, and I know how to use them. However, we can decide for ourselves whether we want to create seperate layers for our DTO's and Interfaces, or to stick them in the logic layer. We are also asked to explain why we chose one option over the other. However, I cannot find any sources for why you would pick one over the other anywhere. So that's why I'm asking here.
So my question is: What are the advantages and disadvantages of putting your DTO's and Interfaces in a seperate layer, and what are the advantages and disadvantages of just keeping them in the logic layer?
Thanks in advance.
What are the advantages and disadvantages of putting your DTO's and Interfaces in a separate layer
I imagine separate layer like this:
Core
|
------------
| | |
DAL BLL PresentationLayer
Advantages are:
can be used in any other layers. So each layer can expose own dto by its API,
but internally it uses own classes. E.g. data layer can use internally own model clases Person,
however data layer returns PersonDto to Business Layer
you can easily reference this separate layer into other layers without forcing to introduce unnecessary
dependencies. E.g., if application is using just one model from data layer, then you will have to reference
this layer into presentation layer.
Disadvantages:
recompiling? If you edit your dto, then you need to recompile your layer and recompile all layers that
depepnds on this layer
what are the advantages and disadvantages of just keeping them in the logic layer?
Advantages:
I do not think that this approach has any advantages
Disadvantages:
wheneever you want to use dto or interface in any other layer, you have to reference the whole
this logic layer. This logic layer can expose unnecessary API for this layer.
I have a book, which talks about design patterns and the use of layers in particular i.e. presentation layer, business logic layer and data access layer.
I now understand the concept of a utility class and a data transfer object. However, all of the examples and information in the book talk about how they apply to the business logic layer.
I assume that they also apply to the data logic layer as well or is there another design pattern that I am unaware of?
This question follows on from a question I asked yesterday, here: VB.NET - Creating objects on every loop.
I will post some code to clarify what I am asking if required, though this is more of a conceptual question.
Utility classes and DTOs are equally at home in the data and presentation layers. I often use DTOs defined in the data layer to pass data "up" to the business layer.
I have some business objects and some very similar corresponding data contract objects for getting data across the wire via WCF service.
What mechanism should I use to get populated data contract objects from business objects?
In an ideal world, should the data contract layer know about the business layer?
or
Should the business layer know about the data contract layer?
or
Should there be another mapping layer that has static methods like GetDataContractFromBusinessObject?
I am a big fan of the "mapping layer with static methods" technique you mention. Then, your business objects and data contracts don't depend on each other either way.
I often will add a derived class to handle data consumption from a specific backing store in my business layer.
Another option is to an interface data layer representation that the business class understands. And then have your data layer implement that interface. I prefer this method as it is much simpler to have you business layer interact with an abstracted version of your data layer then having your data layer understand your business objects.
Just started developing a project using NHibernate and Fluent NHibernate for the mapping and I'm confused. Since the project is going to get more complex over the next months I would like to structure the code into logical layers such as Persistence Layer and Business Logic layer.
I have a business object called Patient that contains logic and validation.
Should Patient class be mapped with the Fluent NHibernate mapping class?
Or should the mapping class map to some Data Access Object, such as PatientDAO and Patient class somehow use PatientDAO?
If 1, isn't my Business logic layer and persistence layer the same?
If 2, having the two layer is separate projects, should I the BL project contain the Patient object and some IPatientDAO and the PL have the PatientDAO object?
Or am I doing it all wrong? :-)
You should map your entities using Fluent NHibernate, since that is where you map to/from your database structure to your object model.
As for DAO, this is a matter of personal taste. Generally folks like to use a DAO of some sort (even though folks like to call them Repositories these days). These classes will utilize the NHibernate ISession to read/write the data to and from the database. Generally the current means of working with these is to define a generic interface with Get<T>(int id), GetAll<T>(), 'Delete()type methods defined to handle CRUD ops, withT` being the entity type.
It is, however, also possible to use the ISession directly in your presentation code, since it is already providing an abstraction for reading/writing data. If you go this route then you are exposing NHibernate to the rest of your app, but your also removing one level of abstraction.
As for which layer is which, NHibernate is 95%-100% of your persistence layer. You can add some abstractions of your own on top of it to create an API that makes you happy, but that is totally up to you.
In Domain Layer or Data access layer?
The primary motivation for DTOs is to present an interface tailored to another layer (typically, the presentation layer). For example, a data entry screen may need some bits of data from a User object in addition to some bits from an Order, etc. In that case, the Domain to DTO should happen at the layer which the presentation layer invokes, i.e., typically a "service" layer.
There are libraries like Dozer out there which automate the grunt work of converting between domain models and DTOs.
The key take away is DTOs are meant to abstract the data (not business logic) out of richer domain model objects - hence, DTOs should be converted back to domain objects as early as possible (at service layer) so the rest of your application layers may work with richer domain objects (data and business logic)
I'm not much of a fan of DTOs, but I say don't do it in the data layer. The data layer deals with model objects and their persistence. Why couple it with other layers by bringing DTOs into it? I'd map them somewhere else, probably between the service and ui tiers, just at the point where they cross the boundary between where they're created and where they're used.
Putting this in MVC context, if you have both controllers and services layer you should put it in the controller. This would make a DTO closer to the view layer and allow the service layer to play with domain objects only, avoiding possible confusion with other models.
The DTO itself is actually the MVC model (Explained here: https://stackoverflow.com/a/1058186).
Below is a recommended tutorial that mashes the controller, service layer and DTO concepts together (In java using Spring framework, but the concept is clear for other platforms as well):
https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application