Rumors are getting louder about the ALT.NET phylosophy, some groups are already born (www.altnet.com, www.altnetpedia.com) and since yesterday UGIALT.net is alive. 

Some friends (makka, simone, luka e antonio) and I have begun this new adventure and many others have already joined us!

The main focus of this group is to discuss about design topics, tools, methodologies and share informations about .NET development.

For now we have opened a yahoo group http://groups.yahoo.com/group/ugialtnet) and a web site (http://ugialt.net).

Everybody is invited to join us.

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

This year I will go to TecheEd Developer in Barcelona from 5th to 10th November. I’ll post in those days the things that I’ll listen and something about the buzz around Barcelona.

So stay tuned

TechEd-Developers