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:

   1:  IList resultWithAliasedBean = s.CreateCriteria(typeof(Enrolment))

   2:   .CreateAlias("Student", "st")

   3:   .CreateAlias("Course", "co")

   4:   .SetProjection(Projections.ProjectionList()

   5:   .Add(Projections.Property("st.Name"), "studentName")

   6:   .Add(Projections.Property("co.Description"), "courseDescription")

   7:  )

   8:  .AddOrder(Order.Desc("studentName"))

   9:  .SetResultTransformer(NHibernate.Transform.Transformers
  10.  .AliasToBean(typeof(StudentDTO)))

  11:  .List();

The Element and StudentDTO is simple enough.

   1:          [Serializable]

   2:      public class Enrolment

   3:  

   4:          private Student student;

   5:          public virtual Student Student

   6:          {

   7:              get { return student; }

   8:              set { student = value; }

   9:          }

  10:  

  11:          private Course course;

  12:          public virtual Course Course

  13:          {

  14:              get { return course; }

  15:              set { course = value; }

  16:          }

  17:  

  18:          private long studentNumber;

  19:          public virtual long StudentNumber

  20:          {

  21:              get { return studentNumber; }

  22:              set { studentNumber = value; }

  23:          }

  24:  

  25:          private string courseCode = string.Empty;

  26:          public virtual string CourseCode

  27:          {

  28:              get { return courseCode; }

  29:              set { courseCode = value; }

  30:          }

  31:  

  32:          private short year;

  33:          public virtual short Year

  34:          {

  35:              get { return year; }

  36:              set { year = value; }

  37:          }

  38:  

  39:          private short semester;

  40:          public virtual short Semester

  41:          {

  42:              get { return semester; }

  43:              set { semester = value; }

  44:          }

  45:  

  46:          public override bool Equals(object obj)

  47:          {

  48:              Enrolment that = obj as Enrolment;

  49:              if (that == null)

  50:                  return false;

  51:              return studentNumber == that.StudentNumber && courseCode.Equals(that.CourseCode);

  52:          }

  53:  

  54:          public override int GetHashCode()

  55:          {

  56:              return courseCode.GetHashCode();

  57:          }

  58:      }

  59:  public class StudentDTO

  60:      {

  61:          private string studentName;

  62:          private string courseDescription;

  63:  

  64:          public StudentDTO() { }

  65:  

  66:          public string Name

  67:          {

  68:              get { return studentName; }

  69:          }

  70:  

  71:          public string Description

  72:          {

  73:              get { return courseDescription; }

  74:          }

  75:      }

What we can do is to retrieve StudentDTO from Presenter by querying from Repository. Code is elegant and beautiful. How sexy NHibernate is!!

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.

How to implement Domain model (object) in DDD?

Inspired by Eric Even’s excellent book, Domain Driven Design,
I have been studying and using domain driven design for a while. There have a lot of advantages offered by implementing DDD in enterprise applications. I will continue to blog what I learned from DDD later. Among those advantage, one of the most important is to clearly lay out the resposibilites for the classs in the doma layer, such as Entity, Value Object, Service, Repository and Fractory. There has a question always in my mind that if we have move application operations to service class. What methods we need to implement for Entity class? We are trying to avoid AnemicDomainModel. So how do we design our Entity class? Here comes the answer:

“The best definition of “domain object” I’ve found in literature is in Chapter
11 of TimHoward’s book TheSmalltalkDevelopersGuideToVisualWorks
pp.379-381:

“a domain object is a logical container of purely domain
information, usually represents a logical entity in the problem domain space …
In general, domain objects should know how to
recognize which [of their]
references indicate aggregation and which ones indicate association
copy
themselves
maintain business logic
compare themselves to other domain
objects of the same type
facilitate other objects that choose to print or
display them
conduct tests on their domain information”
To this list I
would add
identify themselves
validate themselves
–RandyStafford
I would also
add
domain objects direct their persistence
there may be collections of
Domain objects
domain object may contain references to other domain objects
(this is assumed by the first one above).
–Fritz Schenk “

Quote from http://c2.com/cgi/wiki?DomainObject

Data Transfer Object (DTO) in MVP pattern

Jean-Paul Boodhoo from ThoughtWorks has published an excellent article regarding how to implement MVP (Model-View-Presenter) pattern in ASP.NET. It acutally has very similar implementation I am using currently. The only difference is I declear event in the view, so that ASP.NET page use event to notify the presenters, which makes more loosely coupled between ASP.NE page and presenter. I also use DTO (Data Transfer Object) to pass the data through. Although DTO seems as a Core J2EE Pattern, I still have a concern to use it extensively, becasue DTO is totally against the Object-Oriented principals. It promotes a FLAT object, a really value object. Since I have developed my domain objects with NHibernate/Castle ActiveRecord, it duplicates the efforts as well. The main purpose of using DTO is to utilize the ASP.NET databinding features. Paul Wilson seems to work on a solution to map domain objects to UI. It seesm very intertesting. But I have not seen any sample code yet. Anybody has a better solution?

Castle ActiveRecord

In my latest project, I am using Castle ActiveRecord as my ORM. I am very happy with the productivity it provides. Castle ActiveRecord is inspired by ActiveRecord in Ruby on Trail. It is built upon nHibernate, a excellent OR mapping tool ported from Java Hibernate. ORM is still a pretty new topic in .NET development. A lot of .NET developers are not comfortable with ORM becasue of dynamic SQL, worrying about its performance. But from my personal experience, I found the performance lag is from reflection most of time, rather than dynamic SQL. From a application development standpoint, performance is one, but not the only factors we need concern. We need to balance performance, maintainability, productivity, etc. From my perspective, I cannot find a good Application Architecture without taking any advantage of OR mapping. Castle ActiveRecord is excellent framework with Null-handler, validation, lazy loading and other great features built. It saves me significant time to build similar things from scratch. I will keep posting what I learn from ActiveRecord, and other O/R mapping, and how to build solid application based on those framework.