DTO模式+延遲加載+實體框架+ ASP.Net MVC +自動映射器

Question

首先，對不起對於冗長的問題，但我不得不提供一些基礎信息。

我們正在創造它採用ASP.net MVC，JQuery的模板，實體框架，WCF應用程序和我們使用POCO作爲我們領域層。在我們的應用程序中，有一個WCF服務層與ASP.net MVC應用程序交換數據，它使用從WCF到MVC的數據傳輸對象（DTO）。

此外，應用程序通過在我們的WCF服務層轉換域到的DTO時使用AutoMapper使用實體框架延遲加載。

我們的後端架構如下（WCF服務 - >管理 - >庫 - >實體框架（POCO））

在我們的應用中，我們不使用，因爲我們不希望再查看模型MVC應用程序的映射層，我們只使用DTO作爲視圖模型。

一般而言，我們針對域（例如Customer，CustomerLite等）使用普通和精簡DTO。（精簡版對象的屬性比普通少）。

現在我們有因爲我們的DTO結構日趨複雜，當我們認爲可維護性（DTO的與一般的層次結構），我們失去效能與DTO的一些困難。

例如，

我們有客戶視圖頁面和我們的DTO層次結構，如下

public class CustomerViewDetailsDTO 
{ 
    public CustomerLiteDto Customer{get;set;} 
    public OrderLiteDto Order{get;set;} 
    public AddressLiteDto Address{get;set;} 
} 

在這種情況下，我們不希望對這一觀點OrderLiteDto的一些領域。但是其他一些觀點需要這些領域，所以爲了促進它我們使用這個結構。

當涉及到自動映射，映射我們CustomerViewDetailsDTO，我們會得到更多的數據，從延遲加載（實體框架）（它不需要特定視圖）。

我的問題：

1. 有沒有同時考慮可維護性，我們可以使用提高性能的任何機制？

2. 對於同一個DTO，是否可以使用Automapper和更多基於地圖視圖的映射函數？

Answer 1

首先不要使用延遲加載，因爲它可能會導致選擇N + 1問題或類似問題。

選擇N + 1是數據訪問反模式，其中數據庫是 以次優方式訪問。

換句話說，使用惰性加載而不加載集合會導致實體框架轉到數據庫並將結果一次返回一行。

使用jsRender爲模板，因爲它比JQuery的模板快得多： Render Bemchmark ，這裏是如何使用它的一個很好的信息：Reducing JavaScript Code Using jsRender Templates in HTML5 Applications

一般情況下，我們有正常和精簡版的DTO域，如客戶， CustomerLite等（Lite對象具有比正常少的屬性）。

你的普通DTO可能是一個ViewModel作爲的ViewModels可能會或可能不會映射一來一往的DTO，和的ViewModels通常包含邏輯從視圖推回，或幫助與將數據推回模型的用戶響應。 DTO沒有任何行爲，其目的是減少應用程序層之間的調用次數。

有什麼機制可以用來提高性能，同時考慮可維護性嗎？

對一個視圖使用一個ViewModel，您不必擔心可維護性。就個人而言，我通常創建一個基礎的abtract類，編輯，創建或列出我繼承該類並添加特定於視圖的屬性。因此，對於示例創建視圖不需要PropertyId（因爲某人可以劫持您的帖子併發布它），因此只有Edit和List ViewModel具有PropertyId屬性。

對於同一個DTO，可以使用Automapper和更多的基於地圖視圖的映射函數嗎？

您可以使用AutoMapper來定義每個地圖，但問題是地圖將會有多複雜。每個視圖和您的地圖使用一個ViewModel將很容易編寫和維護。我必須指出，這是不推薦使用Automapper數據訪問代碼：

AutoMapper的

一個缺點是從域投影對象 仍然迫使整個域對象要查詢和加載。

來源：Autoprojecting LINQ queries

您可以使用一組擴展的被限制，截至目前在數據訪問代碼的映射加快：Stop using AutoMapper in your Data Access Code

問候