DTOs and IQueryable: assembling and disassembling DTOs

Question

I’m working on a project which uses an Assembler pattern to assemble LinqToEntity entities into Data Transfer Objects at a service level, which are then passed down to the client layer for use. The approach has been to translate the entitie objects into simplified, flat objects that provide information specific to the service call.

Eg.

// Original Entity looks something like this
public class PersonEntity
{
   public int Id { get; set; }
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public int MotherId { get; set; }  
   public PersonEntity Mother { get; set; }
   // lots of other properties
}

// Flattened DTO
public class PersonSummaryInfo
{
  public int Id { get; set; }
  public string FullName { get; set; }
  public string MothersFullName { get; set; }
}

In this example, the assembler would create a PersonSummaryInfo, constructing the FullNames part of the process.

I now face an issue with some 3rd party control (Telerik ASP.NET MVC GridControl), where the control is set up to filter (using IQueryable) based on it’s Model’s properties. There idea seems to be that you have a single tier design and pump your database entities directly into the view, which I can’t stand.

Trying to incorporate it into my logic, the GridControl binds to my DTO instead of the Entity which is all good until it tries to sort anything. I pushed all of the IQueryable stuff into my service in a very Generic fasion to make it reponsible for this. Sorting attempts to sort by, say MothersFullName on the DTO (its behaviour is to pass “MothersFullName” as a string to your sorting logic), this gets pushed up to my service which through reflection attempts to sort the Entities, making use of IQueryable lazy loading, but of course when the query is executed, an Exception is thrown as “MothersFullName” is not a property of the original Entity.

Is there a good strategy that handles this sort of implementation? Is it good practice to effectively “disassemble” a DTO back to its ORM entity once its back in the Service layer of an application? Or is it better to pass down richer objects that have more knowledge of what they are (such as how to sort a full name using FirstName and LastName)?

What is key to my requirements is:

• use fancy Telerik control because they like it
• lazy load results at the service level (ie. dont bring back 2 million records and just display 10)
• support filtering, paging etc
• a sound architectural implementation

Answer 1

You have a couple of options ahead of yourself. First of all it is true that the is able to be bound to a IQueryable, because that is the fastest (and most common) way to do it, in terms of development time of course.

In your case (a full blown Service layer on top of the ORM) the situation is a bit different. I would personally suggest you dig a little bit and provide custom bindings to your grid. You get an GridCommand object that you can query for sorting and filtering and use that to ask your service layer for data. This is a good place to mention an easy way to solve the problem you are facing (this being that your expressions are based on the DTO properties). You can try using Dynamic Linq. Just construct your string queries from the expressions and pass them down to your DAL.

As a matter of fact, this is a suggested best practice by another of Telerik's products the OpenAccess ORM. The OpenAccess SDK contains a couple of examples (especially the WCF Plain Services one) that use a similar architecture to yours. The product also provides a code generation tool that delivers a whole service layer.