使用實體框架實體作為業務對象？
我正在使用 Microsoft 的實體框架 O/R 映射器，並將實體類（映射到 DB 對象的生成類）用作業務對象。這個可以嗎？請說出你的缺點或優點。在業務層和表示之間進行WCF通信的情況下該怎麼辦，如何將這些對像作為數據成員發送？
我以這種方式使用 EF，一個不錯的功能是生成的實體是部分類，允許它們以一種不受再生問題影響的方式進行擴展。
還可以查看MSDN 上的此連結，該連結描述了 EF 在業務邏輯方面的一些常見使用場景。
首先，在撰寫本文時，有 11k 的問題視圖，我對缺乏答案感到有點驚訝，恕我直言，答案的質量，給出了一個相當簡單的問題。
所以，既然我已經發洩了一點，我想解決這個問題，因為我認為它在今天更適用於最近發布的 Entity Framework Code-First。
“使用實體框架實體作為業務對象？”
在我開始之前澄清幾點：
- 當您說“業務對象”時，我的印像是您所指的這些對象包含規則或邏輯，例如從簡單的驗證（即必填欄位）到更複雜的邏輯（即結賬時的處理稅）。
- 我認為我無法回答您關於 WCF 的後續問題。這樣做的原因僅僅是因為我將客觀地回答您關於 EF 作為業務對象的問題，然後主觀地迫使我採取與我試圖真實客觀地回答所述第一個問題的嘗試相矛盾的立場。
也就是說，將您的 EF 作為業務對象問題…
“我正在使用 Microsoft 的實體框架 O/R 映射器，並使用實體類（映射到 DB 對象的生成類）作為業務對象。這樣可以嗎？”
對不起，這裡根本沒有正確或錯誤的答案。這取決於您的目標是什麼，以及在充分了解這樣做的優缺點的同時，您得出的結論是最合理的設計。
“請說出你的缺點或優點”
我很高興你問！我很樂意回答，我希望在考慮到利弊的情況下，您能夠就您是否認為將 EF 用於您的業務對像是“OK”做出明智的決定。通常情況下，我會打破利弊，以便於“消化”，但是，我認為這裡不合適，因為我認為我們會對這樣一個非常有趣的話題做出不公正的對待，而且也很接近和親愛的我的心。
首先，讓我從技術角度談一談……您可以將 EF 對像用作您的業務對象，沒有任何技術阻止您這樣做。事實上，EF Code-First (CF) 通過允許您創建 POCO 並讓您能夠應用數據註釋以進行簡單驗證以及實現 IValidatableObject 以進行更複雜的驗證，從而使這非常容易。很酷，嗯？
討論的核心就在這裡。
EF 或任何 ORM 旨在支持數據管理。它的主要職責是數據，因此您創建的對像是以數據為中心的。所以，如果你也試圖通過行為來設計你的對象，那麼你手頭就有一個難題。簡而言之，這個難題被稱為阻抗失配。想像一下；您的應用程序中有兩個必需的案例：
- 編輯使用者的螢幕
- 顯示使用者資訊的只讀子集的控制項
如果使用 EF（任何風格）或任何 ORM，您可能會傾向於使用相同的“使用者”對象來處理保存使用者以及獲取使用者以提取只讀欄位子集的能力。您這樣做可能是出於以下幾個原因之一：
- 像許多開發人員一樣，我們在教育過程中在我們的大腦中種下了這顆種子，“整合程式碼”是最重要的，或者可能更好地稱為 DRY——不要重複自己，因此您可能會在消極的語境。
- 諸如 EF 4.1 之類的 ORM 具有技術限制（和駭人聽聞的變通辦法），例如將多個 POCO/對象映射到同一個數據庫表，從而迫使您不管您的信念如何。
- 這是啟動和執行應用程序的一種快速簡便的方法
- 它“感覺”是正確的做法
這樣做有好處也有壞處，你可以根據你的意見來看待這是積極或消極的方式。
我想如果你相信程式碼的規範化而不是行為，那麼你已經取得了很大的成功。通過編寫單個對象來處理該實體的數據和業務案例，您可以限制程式碼量，從而可能節省時間。
我想如果你相信程式碼行為的規範化，那麼你就慘敗了。通過節省程式碼，您已經犧牲了設計對象的職責，這可能會使其難以管理，並因此增加了維護成本。
不管您的意見如何，我們可能都同意這個業務對象承擔了多項職責，並且對象的行為（不是數據！）充其量是次要的。它的主要職責是管理數據，次要職責是處理簡單和復雜的業務規則，涉及編輯使用者和顯示只讀使用者資訊。在物件導向設計 (OOD) 中，如果一個對象的設計以其身份和行為為特徵，那麼該對象可能是一個困惑的個體，因為它不符合 OOD 的定義。
從技術角度來看，任何時候您請求使用者對像都會繼承大量成本。當僅顯示只讀資訊的子集時，這可能包括所有屬性和業務規則等內容。
那麼這一切與我是否應該使用 EF 來表示我的業務對像有什麼關係呢？
嗯……雖然在技術上是可行的，但對於是否應該使用 EF 或任何 ORM 來表示您的業務對象，存在不同的理念（有些好，有些壞）。我針對上述這些哲學的核心進行了概要介紹，但 Rocky Lhotka 和 Martin Fowler 等人對它們進行了更詳細的記錄。
您採取的方向很可能取決於應用程序，從哲學角度來看，可能取決於您是理想主義者還是實用主義者。也就是說，我並不是說理想主義者或實用主義者與是否將 EF 用於業務對像有關——它只會影響您對此的看法。
在撰寫本文時，Microsoft 的跡象表明 EF 是為處理業務邏輯而建構的，無論對錯，它們似乎都朝著這個方向發展。EF 不斷發展，某些技術限制正在被取消，因此 EF 最終可能被用於滿足兩全其美的需求。換句話說，最終你也許可以吃到你的蛋糕。
希望這可以幫助。
考慮到 ORM 背後的目的是管理數據，回答一個關於 ORM 的持久性無知是否荒謬的問題。:-) 對不起，我無法抗拒！