locked
DTO Design RRS feed

  • Question

  • User-574293449 posted

    hi,

      I read about DTO design pattern and have some doubts regaridng this

    1. I read that DTO does not depend on any entities or other objects. So how do like this?

    Eg: I have an 2 entities named Employee, Designation

    As per my understanding i declare DTO as below

    public class EmployeeDTO

    {

      public List<Employee> { get; set;}

     public List<Designation { get; set}

    }

    So here entities are known to the DTO. Is my understanding right?

    2. In the above example i used 2 lists in the DTO. In the presentation i join employee and designation. So i in the same round trip i got employee list and also designation list to bind. Likewise we avoid more round trips to db. But my doubt is if Employee and Designation records are very high volume this apporach is right? how this handle that must volume

    Wednesday, October 9, 2013 8:35 AM

Answers

  • User917490724 posted

    Hey I will try and take a stab at it.

    Good resources

    http://stackoverflow.com/questions/725348/poco-vs-dto

    http://martinfowler.com/eaaCatalog/dataTransferObject.html

    Data Transfer Objects exists for batching work together to limit the calls that are needed to be made to a service. So your example of having the DTO combine the values of two other objects does make sense.

    However your DTO most likely would not contain a domain object, but a slim, very flat, serializable representation of the data required to complete the work. DTO's also need to be serializable, and your domain object might not be able to be serializable. Your domain objects might contain a lot of business logic, where a DTO should not be able to complete work against itself.

    Again for a DTO to make the most sense it should not have a reliance on your domain layer, however a transformation should be applied. turning ito into a domain layer object and then saved to the database. That way if your domain layer changes, the mapping is the only thing to change.

    Your technology choice is really what is going to be used to define how the objects get from code to the database. DTO's help you reduce the load over the network as data is being sent from client to server, not from server to database.

    I hope some of this helps and I have not confused you more.

    Good luck!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, March 3, 2014 4:20 PM
  • User917490724 posted

    DTO's are not used between any data layers. DTO's are only used between "Expensive" layers, such as web services.

    As for your new example, I would always recommend an approach such as a ViewModel, or a Model that is bound directly to the view. That way you can take the data you recieve from your service / database / xml document, and map it into something that is agnostic to the domain models (Meaning your back end models).

    There is nothing wrong with sending a list of employees back, however understand that a change to the employee model shouldn't be cascaded all the way to your view. This can be stopped by using the Assembler (The work that takes the DTO and transforms it into models that make sense), or any other layer or logic.

    Just be careful returning entities from Entity Framework, or whatever database layer you are using and passing them directly to the view. It will cause a lot of issues as you change your database models.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 11, 2014 10:06 AM

All replies

  • User-574293449 posted

    Any help please

    Tuesday, October 15, 2013 9:52 PM
  • User917490724 posted

    Hey I will try and take a stab at it.

    Good resources

    http://stackoverflow.com/questions/725348/poco-vs-dto

    http://martinfowler.com/eaaCatalog/dataTransferObject.html

    Data Transfer Objects exists for batching work together to limit the calls that are needed to be made to a service. So your example of having the DTO combine the values of two other objects does make sense.

    However your DTO most likely would not contain a domain object, but a slim, very flat, serializable representation of the data required to complete the work. DTO's also need to be serializable, and your domain object might not be able to be serializable. Your domain objects might contain a lot of business logic, where a DTO should not be able to complete work against itself.

    Again for a DTO to make the most sense it should not have a reliance on your domain layer, however a transformation should be applied. turning ito into a domain layer object and then saved to the database. That way if your domain layer changes, the mapping is the only thing to change.

    Your technology choice is really what is going to be used to define how the objects get from code to the database. DTO's help you reduce the load over the network as data is being sent from client to server, not from server to database.

    I hope some of this helps and I have not confused you more.

    Good luck!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, March 3, 2014 4:20 PM
  • User-574293449 posted

    Thanks friend. I got it and some confusion in the second paragraph only.

    So i got the following points

    1. DTO is deserialized format of data

    2. This is an object or entity to pass data between layers 

     

    So my example is nott good one. Actually instead of all employee list  and list of  all designations and i need to create DTO like single object with employee name, designation etc. (like deserialized data). Ok here this is good for Report pages etc like simple bind the data .

    But if i have apge with grid and combo box. I need to bind the grid based on the designation. Here i need to bind the designation combo box and grid. Like this approach i need to get List of Designation as different and List of employees as different. am i right?

    Tuesday, March 11, 2014 8:34 AM
  • User917490724 posted

    DTO's are not used between any data layers. DTO's are only used between "Expensive" layers, such as web services.

    As for your new example, I would always recommend an approach such as a ViewModel, or a Model that is bound directly to the view. That way you can take the data you recieve from your service / database / xml document, and map it into something that is agnostic to the domain models (Meaning your back end models).

    There is nothing wrong with sending a list of employees back, however understand that a change to the employee model shouldn't be cascaded all the way to your view. This can be stopped by using the Assembler (The work that takes the DTO and transforms it into models that make sense), or any other layer or logic.

    Just be careful returning entities from Entity Framework, or whatever database layer you are using and passing them directly to the view. It will cause a lot of issues as you change your database models.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 11, 2014 10:06 AM
  • User831885415 posted

    1. DTO classes are just plain classes that are used to transfer the data between layers

    2. It may not depending any other layer

    3. Optionally It may depend on System.ComponentModel.DataAnnotations; , if you want the DTO to use as View Model in presentation

    4. Not to have too much metadata. b'coz it difficult the serialization over the wire

    Tuesday, July 15, 2014 2:51 AM