複雜的DAL - > BL映射使用AutoMapper

我正在考慮在即將推出的項目中使用AutoMapper並試圖找到可能的「瓶頸」。目前我能想象到的最複雜的情況如下：在數據庫中表示爲3（例如）表的域類（我的數據訪問層是LINQ to SQL）。爲了構建類別i需要執行3個查詢的一個實例：通過從ID表B中複雜的DAL - > BL映射使用AutoMapper

通過從表A中選擇ID（1行，直接進入Class屬性）
選擇（0..1行，去選購Class.Code屬性）
選擇由表C中編號（0..N行，去Class.Parameters集合）

，我不知道如何配置的映射。下面是我考慮的選擇：

執行3個查詢和映射Tuple<A,B,C> - >Class
聯合使用查詢1和2外連接（更有效的）。但是，我如何處理匿名類型？
將datacontext注入到映射中，定義A→Class映射並讓類型轉換器完成這項工作？

沒有看起來像一個勝利。你會建議什麼？那麼，這種複雜的情況是非常罕見的（10-20％），我可以手動完成，剩下的80-90％與AutoMapper一樣好。但我想知道AutoMapper是不是爲這種策略設計的，或者我錯過了一些重要的東西。

來源

2010-10-10 UserControl

有什麼方法可以利用數據庫視圖來執行步驟1-3？然後你可以在視圖對象和你的類之間建立一個簡單的1：1映射。 – PatrickSteele 2010-10-12 11:53:55

感謝您的關注！從技術上講，我可以創建一個視圖，執行1和2之間的外連接，然後完全連接3，但這樣的非規範化絕對不是我想要的（從db增加網絡流量和更復雜的地圖邏輯來處理空值，對不對？）。 – UserControl 2010-10-12 12:20:25

您的問題很難回答，因爲域對象如何以及在何處獲取其數據並不是AutoMapper的關注點。從AutoMapper documentation：

AutoMapper是面向模型投影場景變平複雜對象模型的DTO和其它簡單的對象，其設計是更適合系列化，通信，消息收發，或僅僅是域名和應用層之間的反腐敗層。

但是，這並不意味着您使用AutoMapper不應該考慮到您的域對象背後的思維過程。作爲一個例子懶惰加載想起來。例如在你的情況下，如果你在Class.Parameters屬性上使用延遲加載，但是隨後通過AutoMapper運行該屬性，數據將始終加載。這就是爲什麼遵守one model per view的規則很重要。

Jimmy Bogard是AutoMapper的創造者之一，他討論了他對AutoMapper在AutoMapper: the Object-Object Mapper中的作用。我希望我能直接鏈接到它，但在一個評論回覆對上述職位博加德說：

這件事情我們已經看過了而（雙向綁定），但在結束，我們發現在更新中只有太多的業務驗證。

取而代之，我們圍繞從消息/表單更新模型形成了其他模式。有關更多詳細信息，請參閱Code Camp Server 源代碼。

如上所述，您可以在源代碼中找到大量使用AutoMapper的CodeCampServer。 CodeCampServer代碼的簡化版可以在ASP.NET MVC 2 in Action提供的source code中找到。

來源

2010-10-22 22:03:26 ahsteele

因此，它有點「摺疊」與「展開」的情況下，AutoMapper的設計只支持「摺疊」？我絕對需要重溫我如何使用它。 – UserControl 2010-10-23 08:05:21

@UserControl我更新了我的答案，討論雙向「摺疊」。 – ahsteele 2010-10-23 16:12:27

它應該是一個看你的對象模型的判斷性決定。

優點：

Automapper是一件好事，如果類直接映射到實體類屬性名相匹配table.columnname。
Automapper無縫映射集合。
您可以創建Automapper配置文件並驗證您的配置。
您可以在應用程序級別有一個日期時間，金錢等格式化程序。
你可以選擇填充空白或任何你想要的字符。
忽略（）在許多情況下派上用場。

缺點：

例外在映射是困難的，有時進行調試。
如果有很多解析器，你的代碼看起來很混亂。
在複雜的對象結構中，您可能會解析爲幾個類指定映射。因此不一致。

來源

2010-10-23 16:22:49 anivas

複雜的DAL - > BL映射使用AutoMapper

回答

相關問題