locked
What is difference between DTO and POCO classes RRS feed

  • Question

  • User264732274 posted

    please discuss  difference between DTO and POCO classes with example DTO classes and also discuss when people use DTO class in real life with example code.

    thanks

    Tuesday, January 12, 2016 9:29 AM

Answers

  • User37182867 posted

    POCO is the more generic term for creating classes that do stuff and hold data. DTO would be a subset of POCO with the specific intention of being a Data object. The easiest way to transfer data from one place to another is to wrap all the data that you intend to send in a serializable class. DTO objects are dumb, they have no behavior bulit into them unlike POCO. They are only meant to transfer the state of the data from one place to another. The DTO classes could then be converted to XML and sent as a string and then converted back to a class in the other system. While POCO's might have behavior DTO's do not. 

    For more info go here

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

    When would you use a DTO? When you want to transfer data from one system or application layer to another. When using SAO design patterns the UI is unaware of anything other than its service layer. The service layer and the UI define a contract or DTO objects to communicate with one another. While your SAO may have a robust POCO business layer that uses the DTO objects the data layer nor the UI would know nothing about it. 

    You might design your system this way to keep each layer independent of each other. This allows for portability, scalability and testability of your app. Because the layers of independent of one another, you could wire up the UI to a test implementation of your business layer which only outputs dummy data. This would allow you to test your UI separately from your business layer or your database layer. 

    Taking this a step further, you could have teams working independently of each other while working on the same project by agreeing upon the DTO's (Data contract) ahead of time. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, January 12, 2016 12:45 PM
  • User-821857111 posted

    POCO:

    public class Person
    {
        public int Id {get;set;}
        public string Name {get;set;}
        public void Talk()
        {   
            Console.WriteLine("Hello");
        }
    }

    DTO (no behaviour):

    public class PersonDTO
    {
        public int Id {get;set;}
        public string Name {get;set;}
    }

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, January 12, 2016 1:37 PM
  • User-1611549905 posted

    There's just one thing I'd like to clear up here.

    DTO stands for Data Transfer Object. It is used to transfer data between one process and another. It should not be used to transfer data between two layers operating within the same process.

    DTOs have completely different design considerations from your models or view models. Within a process, object instantiation is cheap, and objects can easily be shunted between one layer and another. As such, you can make your models as fine-grained as you need to, and implement caching patterns (unit of work/identity map/query caches) to reduce database chatter.

    On the other hand, when you are communicating between processes, queries and object instantiation are expensive. You want to bundle up your data into as few requests as possible. A DTO will therefore often consist of several collections of objects bundled together into a single request, so for instance it might look like this:

    public class BlogDTO
    {
        public IList<PostDTO> Posts { get; set; }
        public IList<CommentDTO> Comments { get; set; }
        public IList<UserDTO> Authors { get; set; }
    }

    whereas in the same process, your business layer would return the lists of posts, comments and authors as separate queries.

    The reason I say this is that I've seen projects where Repository classes convert models into "DTOs" with identical sets of properties before sending them to the business layer, and then convert them into "View Models" again with identical sets of properties before sending them to the controllers. I really, really detest this kind of approach, since it just adds unnecessary code duplication and friction without delivering any benefit whatsoever. If your models are all POCOs, they won't be taking a dependency on Entity Framework or any other external component, so you don't need to map them or anything in order to test them.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 13, 2016 9:38 AM

All replies

  • User37182867 posted

    POCO is the more generic term for creating classes that do stuff and hold data. DTO would be a subset of POCO with the specific intention of being a Data object. The easiest way to transfer data from one place to another is to wrap all the data that you intend to send in a serializable class. DTO objects are dumb, they have no behavior bulit into them unlike POCO. They are only meant to transfer the state of the data from one place to another. The DTO classes could then be converted to XML and sent as a string and then converted back to a class in the other system. While POCO's might have behavior DTO's do not. 

    For more info go here

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

    When would you use a DTO? When you want to transfer data from one system or application layer to another. When using SAO design patterns the UI is unaware of anything other than its service layer. The service layer and the UI define a contract or DTO objects to communicate with one another. While your SAO may have a robust POCO business layer that uses the DTO objects the data layer nor the UI would know nothing about it. 

    You might design your system this way to keep each layer independent of each other. This allows for portability, scalability and testability of your app. Because the layers of independent of one another, you could wire up the UI to a test implementation of your business layer which only outputs dummy data. This would allow you to test your UI separately from your business layer or your database layer. 

    Taking this a step further, you could have teams working independently of each other while working on the same project by agreeing upon the DTO's (Data contract) ahead of time. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, January 12, 2016 12:45 PM
  • User264732274 posted

    can u give here two class structure for POCO and DTO?

    Tuesday, January 12, 2016 1:06 PM
  • User-821857111 posted

    POCO:

    public class Person
    {
        public int Id {get;set;}
        public string Name {get;set;}
        public void Talk()
        {   
            Console.WriteLine("Hello");
        }
    }

    DTO (no behaviour):

    public class PersonDTO
    {
        public int Id {get;set;}
        public string Name {get;set;}
    }

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, January 12, 2016 1:37 PM
  • User-1611549905 posted

    There's just one thing I'd like to clear up here.

    DTO stands for Data Transfer Object. It is used to transfer data between one process and another. It should not be used to transfer data between two layers operating within the same process.

    DTOs have completely different design considerations from your models or view models. Within a process, object instantiation is cheap, and objects can easily be shunted between one layer and another. As such, you can make your models as fine-grained as you need to, and implement caching patterns (unit of work/identity map/query caches) to reduce database chatter.

    On the other hand, when you are communicating between processes, queries and object instantiation are expensive. You want to bundle up your data into as few requests as possible. A DTO will therefore often consist of several collections of objects bundled together into a single request, so for instance it might look like this:

    public class BlogDTO
    {
        public IList<PostDTO> Posts { get; set; }
        public IList<CommentDTO> Comments { get; set; }
        public IList<UserDTO> Authors { get; set; }
    }

    whereas in the same process, your business layer would return the lists of posts, comments and authors as separate queries.

    The reason I say this is that I've seen projects where Repository classes convert models into "DTOs" with identical sets of properties before sending them to the business layer, and then convert them into "View Models" again with identical sets of properties before sending them to the controllers. I really, really detest this kind of approach, since it just adds unnecessary code duplication and friction without delivering any benefit whatsoever. If your models are all POCOs, they won't be taking a dependency on Entity Framework or any other external component, so you don't need to map them or anything in order to test them.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 13, 2016 9:38 AM