DTO Pattern + Lazy Loading + Entity Framework + ASP.Net MVC + Auto Mapper - asp.net-mvc

Question

Firstly, Sorry For lengthy question but I have to give some underlying information.
We are creating an Application which uses ASP.net MVC, JQuery Templates, Entity Framework, WCF and we used POCO as our domain layer. In our application, there is a WCF Services Layer to exchange data with ASP.net MVC application and it uses Data Transfer Objects (DTOs) from WCF to MVC.
Furthermore, the application uses Lazy Loading in Entity Framework by using AutoMapper when converting Domain-TO-DTOs in our WCF Service Layer.
Our Backend Architecture as follows (WCF Services -> Managers -> Repository -> Entity Framework(POCO))
In our application, we don't use View Models as we don't want another mapping layer for MVC application and we use only DTOs as View Models.
Generally, we have Normal and Lite DTOs for domain such as Customer, CustomerLite, etc (Lite object is having few properties than Normal).
Now we are having some difficulties with DTOs because our DTO structure is becoming more complex and when we think maintainability (with general Hierarchical structure of DTOs) we lose Performance.
For example,
We have Customer View page and our DTO hierarchy as follows
public class CustomerViewDetailsDTO
{
public CustomerLiteDto Customer{get;set;}
public OrderLiteDto Order{get;set;}
public AddressLiteDto Address{get;set;}
}
In this case we don't want some fields of OrderLiteDto for this view. But some other view needs that fields, so in order to facilitates that it we use that structure.
When it comes to Auto Mapping, we map CustomerViewDetailsDTO and we will get additional data (which is not required for particular view) from Lazy Loading (Entity Framework).
My Questions:
Is there any mechanism that we can use for improving performance while considering the maintainability?
Is it possible to use Automapper with more map view based mapping functions for same DTO ?

Answer 1

First of don't use Lazy Loading as probably it will result in Select N+1 problems or similar.
Select N + 1 is a data access anti-pattern where the database is
accessed in a suboptimal way.
In other words, using lazy loading without eager loading collections causes Entity Framework to go to the database and bring the results back one row at a time.
Use jsRender for templates as it's much faster than JQuery Templates:
Render Bemchmark
and here's an nice info for how to use it: Reducing JavaScript Code Using jsRender Templates in HTML5 Applications
Generally, we have Normal and Lite DTOs for domain such as Customer,
CustomerLite, etc (Lite object is having few properties than Normal).
Your normal DTO is probably a ViewModel as ViewModels may or may not map one to one to DTOs, and ViewModels often contain logic pushed back from the view, or help out with pushing data back to the Model on a user's response.
DTOs don't have any behavior and their purpose is to reduce the number of calls between tiers of the application.
Is there any mechanism that we can use for improving performance while considering the maintainability?
Use one ViewModel for one view and you won't have to worry about maintainability. Personally i usually create an abtract class that is a base, and for edit,create or list i inherit that class and add properties that are specific for a view. So for an example Create view doesn't need PropertyId (as someone can hijack your post and post it) so only Edit and List ViewModels have PropertyId property exposed.
Is it possible to use Automapper with more map view based mapping functions for same DTO ?
You can use AutoMapper to define every map, but the question is, how complicated the map will be. Using one ViewModel per view and your maps will be simple to write and maintain. I must point out that it is not recommended to use Automapper in the data access code as:
One downside of AutoMapper is that projection from domain objects
still forces the entire domain object to be queried and loaded.
Source: Autoprojecting LINQ queries
You can use a set of extension that are limited as of now to speed up your mapping in data access code: Stop using AutoMapper in your Data Access Code
Regards