Create DTO with NHibernate

My previous blog is about using DTO in UI/Presenter layers. Just studying Nhibernate source code now, I find a very interesting approach to populate DTO object directly from Nhibernate with Criteria and Projections.
Here is the code:

IList resultWithAliasedBean = s.CreateCriteria(typeof(Enrolment)) .CreateAlias("Student", "st") .CreateAlias("Course", "co") .SetProjection(Projections.ProjectionList() .Add(Projections.Property("st.Name"), "studentName") .Add(Projections.Property("co.Description"), "courseDescription")) .AddOrder(Order.Desc("studentName")) .SetResultTransformer(NHibernate.Transform.Transformers .AliasToBean(typeof(StudentDTO))) .List();

 
[Serializable]
public class Enrolment
{
   private Student student;
   public virtual Student Student
   {
        get { return student; }
        set { student = value; }
   }
  
   private Course course;

   public virtual Course Course
   {
       get { return course; }
       set { course = value; }
   }
   
   private long studentNumber;

   public virtual long StudentNumber
   {
     get { return studentNumber; }
     set { studentNumber = value; }
    }
  
    private string courseCode = string.Empty;

    public virtual string CourseCode
    {
      get { return courseCode; }
      set { courseCode = value; }
    }

  private short year;

  public virtual short Year
  {
   get { return year; }
   set { year = value; }
  }

  private short semester;
  public virtual short Semester
  {
   get { return semester; }
   set { semester = value; }
  }

 public override bool Equals(object obj)
 {
   Enrolment that = obj as Enrolment;
   if (that == null)
          return false;
   return studentNumber == that.StudentNumber && courseCode.Equals(that.CourseCode);
}
 public override int GetHashCode()
 {
     return courseCode.GetHashCode();
 }

}
public class StudentDTO
{
    private string studentName;
    private string courseDescription;
    public StudentDTO() { }
    public string Name
    {
        get { return studentName; }
     }
    public string Description
    {
        get { return courseDescription; }
    }
}

DTO (Data Transfer Object) in Domain Driven Design

DTO (Data Transfer Object)is a very common used pattern in enterprise applications. Martin Fowler also documented it in his class book “Pattern Enterprise Application Architecture“. In the meanwhile, DTO is also a very famous “Anti-Pattern”. The pure OO purist think DTO is a devil. It is so easy to build. The object become nothing but a simple data container, which represent the data in the tables instead of the real domain objects. The business logic embedded in the application is going to shift from middle domain logic tier to tables, most of time spreaded among the stored procedures, which is leading to a unmaintainable solution.

So should we give up DTO totally in our application design? Absolutely not, in the other end, I find DTO still useful especially in UI and UI process layers. For example, we have a complex searching page to find customer by first name, last name, SSN, address, phone, email, and so on. those information may stay in different domain objects. It is also very hard to design a method with a very long list of parameters, not just ugly but also unmaintainable. My approach is to design DTO object pass data between UI and UI process (Presenter or Controller). Then access the service objects, and domain objects from presenter/controller. So I can design domain entity with the interfere from the special requirement of UI. Again it is important to implement MVP pattern to protect the domain object, which is also one of the important principles I heard from DDD: don’t leak business logic out of the domain object layer.