When the book of Andrea and Dino came out I bought a copy that I read during the Christmas holidays. The book, after the dedication that Andrea do to Depeche Mode, opens talking about Architects and Architectures giving some definitions. The second chapter is on UML.

The good starts from chapter 3 where the basic OOP principle will be presented and where the authors talks about Patterns, di SoC, SRP, Liskov, OCP etc….

The central part of the book is dedicated to the three layers: in the 4Th they present the Domain Model, the Transaction script and all that the business layer need. In the 5Th they talk about Service Layer, then in the 6th comes the DataLayer and in the 7Th the Presentation Layer.

These 4 chapters are discussed using the patterns and showing a lot of code from the NSK codebase. The authors touch also  some correlated arguments like AJAX, SOA, DAO, MVC, etc…

I really like the book and I think that is a good addendum to the Fowler’s book because filled with real code samples.

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....]