This post should close the DTO (or ObjectView) series

In the last post I shown an elegant solution to the DTO implementation using a class that wrap the Domain Model Objects. That solution is, for what I seen, the most used but in this post I would like to show a third possible implementation.

The only little thing of the wrapper solution is that the DTO depend from the Domain Model Oject because internally it has a reference to the Employee class. To remove this dependency we could design a class that contains only the properties to use on the User Interface without the reference to Employee. For example:

    public class EmployeeDTO
    {
        private String _name;
        private String _fullAddress;
      Â
        public String Name
        {
            get { return _name; }
            set { _name = value; }
        }
  Â
        public String FullAddress
        {
            get { return _fullAddress; }
            set { _name = _fullAddress; }
        }
    }

This solution provide a purely container object that has no reference to the Domain Model. But it raise another little problem. Who fill this class with the right data? The service layer is responsible to transform the Domain Objects in these DTOs and a lot of mapping code should be written.

So as usual theres no one best solution, every context has it’s right solution.

In the previous post we discussed the problem of Domain Model Pollution with properties that serves the user interface needs. We close the post nominating the DTO’s. 

What is a DTO?

A DTO, in this case, is an anemic object (only properties no methods) that serve only one need: trasport information from the application layer to the user interface (and eventually back).

In the example of last post, the solution to the binding problem can be resolved using a DTO in this way: 

public class EmployeeDTO : Employee

{

    public String FullAddress

    {

        get { return String.Format("{0}, {1}", Address.Street, Address.City);}

    }

}

The object EmployeeDTO use inheritance for having all the properties of the object Employee with the addition of properties FullAddress.

The proposed solution, even if is immediate and simple, is not the best one. The problem is that the object EmployeeDTO inherits from Employee and so it’s have all the public (and protected) properties and methods becoming too rich to be used in a simple manner: the developer can loose the perception that EmployeeDTO is only a data container because he can use all the methods of Employee.

In addition to this problem, there is a second one. Suppose that you need to expose the property Name of the class Employee on the user interface and make the first letter uppercase (only for presentation). In the class EmployeeDTO I should override the property Name, but it isn’t defined virtual in the base class so I can’t do it. Then? The problem of pollution came back: I should mark the property Name as virtual.

A better solution to these problems is in one of the base principle of Object Oriented Development:  “Favor encapsulation over inheritance”.

[To be continued....] 

When we develop application using a DDD methodology we are going to create a Domain Model and often we feel the need to add properties to the domain model objects which serve the need to flattern the object graph to simplify the data binding on the user interface.
To understand what i mean consider the following sample on Employee object:

public class Employee
{
    private String _name;
    private Address _address;

    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }
    public Address Address
    {
        get { return _address; }
        set { _address = value; }
    }
}
public class Address
{
    private String _street;
    private String _city;

    public string Street
    {
        get { return _street; }
        set { _street = value; }
    }
    public string City
    {
        get { return _city; }
        set { _city = value; }
    }
}

Suppose that we need to show on an ASP.NET page the list (a GridView) of all the Employees with Name and full Address. Sadly ASP.NET doesn’t support the binding of inner objects and then we cannot bind the property “Address.Street”.

The first solution that comes to mind is to add a new FullAddress property like this:

public classs Employee
{
    // ....
    public String FullAddress
    {
        get { return String.Format("{0}, {1}", Address.Street, Address.City;}
    }
}

Doing this way the binding is simple but the Domain Model will be polluted with properties that not belong the domain logic e if these properties grow up in number the DM became difficul to mantain and less rapresentative of the business logic that was build for.

How can we resolve the problem leaving the DM fresh?
Â
We can introduce the concept of DTO (Data Tranfer Object), simple objects that act as a trasporter of data to the user interface.
Â
[To be continued....]