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:
Went with this solution.
Create sql Views containing the Grid specific columns. Then made data transfer objects use properties that exactly match those of the View. Not the cleanest or strongest way to achieve this, but at least it gets my Data references out of my projects that don't need it.
Did not use dynamic linq, instead kept my generic approach and used reflection to get column names for matching. Did not go for Telerik's Open Access just because we already have a whole service layer implemented, but it sounds like a nice solution.
It's all still IQueryable, so efficiently it works very very well (just relies on developers to ensure the GridViews match the GridViewModels, property for property).