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
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 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.
I'm looking for how to structure the layer of my app between the presentation layer and the model / business object layer. I see examples using Controller classes and others using Service classes. Are these the same things with different names for different methodologies, or is there a more fundamental difference?
Edit:
To put the question in context, this is a PHP app using Doctrine as the ORM.
I would say terms like Controller are basically same names for potentially very different things depending on what methodology / framework you are using. At a very high level, they may perform the same action - hence the generic name usage - but their responsibilities and scope within the context of the framework will usually be much more specific and different.
Eg: The Controller in MVC has little or nothing in common with the Controller layer in WCSF.
I think these terms like Controller / Service etc are generic and hence have been used in many frameworks but they have a special meaning within the framework of reference.
Also, specifically, a controller and a service to me are two completely differing concepts.
Controller is something like a layer that is responsible for orchestrating logic within the application / or an aspect of the application
Service , to me, is basically the external API through which you expose aspects of your application in a standard manner
I have a repository (CustomerRepository) that retrieves data from the data layer. Most of the business logic is in the entity class (Customer) that the repository either accepts or returns.
However, where do you put the global entity business logic (that applies to all customers)?
For instance, I may not want to return all customers to certain users. I don't want to put that logic in the repository.
I agree with Robert Munteanu.
Basically you roll up your business logic that isn't inherent in your model into a middle tier. The middle tier is the business tier / business objects / business logic layer / etc, but is just referred to as a service tier. It doesn't have to be a webservice, its a broad use of the term service in that it aggregates functionality of a specific application area.
You would basically have a CustomerService class that contains the repository reference. Your presentation layer would reference the service layer class.
There is an additional distinction that can be made as a guess from your name you are using .net, and probably using LINQ to SQL as your repository as outlined in NerdDinner.
The Repository typically returns IQueryable to the service layer, allowing the service layer chain together multiple queries to build different result sets. The Service then evaluates the expression using ToList or another similar method and returns that to the presentation layer.
Put it in another repository (BusinessRuleRepository) and have CustomerRepository use it.
OR
If the business logic is only limiting the results a user can see you might want to use a Facade pattern with a factory. In this case you would have an ICustomerRepository that handles your CustomerRepository and LimitedCustomerRepository (which might encapsulate CustomerRepository), and a CustomerRepositoryFactory that returns the appropriate ICustomerRepository for the user.
Wrap it behind a service.
I think separating these types of functions into a service layer is the way to go.
I recently built a system to do complex forecasting with many entities using historical data. Putting all the data access bits in the repository for each entity. The intricate forecasting logic I kept in a service layer and passed the repository objects in as needed.
Added bonus was that I had an easy way to expose all the forecasting logic to external systems by simply creating a web api layer.
We are building a service-oriented system where we have separated the application into several layers:
SOAP web services (e.g., BuildingService.asmx)
Business logic layer (e.g., BuildingXXX)
Data Access layer (e.g, BuildingProvider)
Types (e.g., Building)
The SOAP web services simply instantiate an object of type BuildingXXX from the business logic layer in order to keep the implementation out of the SOAP web services. BuildingXXX then uses the BuildingProvider from the data access layer to return types defined in the data transfer object layer.
We have been unable to determine what we should call the objects in the business logic layer.
What is the "standard" naming convention for naming these business level entities?
Personally, I would call your business logic layer services "BuildingService" then call the web services "BuildingWebService".
Or you could always go with the generic "BuildingManager" as well for the service layer..
Namespaces are your friends. How about BusinessLayer.Building, BusinessLayer.Facility? Use DataLayer.Building, DataLayer.Facility, etc. You get to call things what they are, yet they get to be different things.
I would naively go with BuildingRules (since this is what they are, right?) but then I don't actually know what are the conventions...
i prefer prefixes instead of suffixes, so that the related layers sort together, e.g.
BizRuleBuilding,
BizRuleFacility,
...