使用Entity Framework實體作為業務對象?

.net architecture entity-framework

我正在使用Microsoft的Entity Framework O / R映射器,並使用實體類(映射到DB對象的生成的類)作為業務對象。這個可以嗎?請說明你的缺點或專業人士。如何在業務層和演示文稿之間進行WCF通信,如何將這些對像作為數據成員發送?

一般承認的答案

我以這種方式使用EF,一個很好的特性是生成的實體是部分類,允許它們以一種相當受保護的方式進行擴展,以防止再生問題。

另請參閱MSDN上的此鏈接該鏈接描述了與業務邏輯相關的EF的一些常見使用場景。


熱門答案

首先,在寫這篇文章的時候有11k的問題觀點,我對於答案的缺乏和所有應有的尊重,答案的質量,給出一個相當直接的問題感到有些驚訝。

所以,既然我已經發布了一點點,我想解決這個問題,因為我認為它今天更適用於最近發布的Entity Framework Code-First。

“使用Entity Framework實體作為業務對象?”

在我開始之前有幾點澄清:

  • 當您說“業務對象”時,我的印像是您引用的這些對象包含規則或邏輯,例如,簡單驗證(即必需字段)到更複雜的邏輯(即結賬處理稅)。

  • 我不認為我可以回答你關於WCF的後續問題。這樣做的原因很簡單,因為我會客觀地回答你關於EF作為商業對象的問題,然後主觀地迫使我採取立場,證明我真實和客觀地回答第一個問題的嘗試是矛盾的。

那說,作為業務對象的問題,你的EF ...

“我正在使用Microsoft的Entity Framework O / R映射器,並使用實體類(映射到數據庫對象的生成類)作為業務對象。這樣可以嗎?”

對不起,這裡根本就沒有對錯的答案。這取決於您的目標是什麼以及您認為最合理的設計,同時充分理解這樣做的優點和缺點。

“請說明你的缺點或優點”

我很高興你問!我很樂意回答,我希望這裡有一個優點和缺點,你能夠做出明智的決定,你是否相信使用EF作為你的業務對像是“OK”。通常情況下,我會突破優點和缺點,使其易於“消化”,但是,我不認為這是合適的,因為我認為我們對這樣一個非常有趣的話題不公正這也是我的心臟附近和親愛的。

首先,讓我在技術上談一下 - 你可以使用EF對像作為業務對象,技術上沒有任何東西阻止你這樣做。事實上,EF Code-First(CF)允許您創建POCO並使您能夠應用數據註釋進行簡單驗證以及實現IValidatableObject以進行更複雜的驗證,從而使這非常容易。很酷,嗯?

這就是討論的核心。

EF或任何ORM旨在支持數據管理。它的主要職責是數據,因此您創建的對像是以數據為中心的。所以,如果你試圖通過行為來設計你的對象,那麼你手頭上就會有一些難題。簡而言之,這個難題被稱為阻抗不匹配。想像一下;您的應用程序中有兩個必需的用例:

  1. 用於編輯用戶的屏幕
  2. 用於顯示用戶信息的只讀子集的控件

如果使用EF(任何風格)或任何ORM,您可能傾向於使用相同的“用戶”對象來處理保存用戶的能力以及提取用戶拉取只讀字段的子集。您可能出於以下幾個原因之一這樣做:

  1. 像許多開發人員一樣,我們在教育過程中將這種種子植入我們的大腦中 - “鞏固代碼”至關重要,或者更好地稱為DRY - 不要重複自己,因此您可能會看到重複的代碼,例如作為屬性,在負面背景下。
  2. ORM,例如EF 4.1,具有技術限制(以及破解解決方法),例如將多個POCO /對象映射到同一個數據庫表,從而迫使您不管您的信念如何。
  3. 這是一種快速簡便的方法來啟動和運行應用程序
  4. 它“感覺”是正確的做法

這樣做有利有弊,您可以根據自己的意見看待這種方式是積極的還是消極的。

我想如果你相信代碼優於行為的規範化而不是你已經成功了。通過編寫單個對象來處理該實體的數據和業務用例,您可以限制代碼量,從而節省時間。

而且我想如果你相信代碼的行為正常化而不是你失敗了。通過節省代碼,您犧牲了設計對象的責任,這可能會使管理變得困難並隨後增加維護成本。

無論您的意見如何,我們都可能都同意這個業務對象承擔了多重責任,並且對象的行為(而不是數據!)充其量只是次要的。其主要職責是數據管理,其次要職責是處理業務規則,既簡單又復雜,涉及編輯用戶和顯示只讀用戶信息。在面向對象設計(OOD)中,如果對象的設計以其身份和行為為特徵,那麼這個對象可能是一個混淆的個體,因為它不遵循OOD的定義。

從技術角度考慮的事情,每當您請求用戶對象時,您都會繼承大量的開銷。當僅顯示只讀信息的子集時,這可能包括諸如所有屬性和業務規則之類的內容。

那麼所有這些與我是否應該使用EF來表示我的業務對像有什麼關係呢?

好吧......雖然技術上可行,但是你是否應該使用EF或任何ORM代表你的業務對像有不同的哲學(一些好的,一些壞的)。我給出了一個針對上述哲學核心的概要,但是Rocky Lhotka和Martin Fowler等人更詳細地記錄了這些概要。

你所採取的方向很可能取決於應用程序,從哲學的角度來看,可能取決於你是多少理想主義者或實用主義者。也就是說,我並不是說一個人是理想主義者或實用主義者,而是將EF用於商業對象,或者不是 - 它只會影響你對此的看法。

在撰寫本文時,微軟表示,EF是為處理業務邏輯而構建的,無論對錯,它們似乎都朝著這個方向發展。 EF正在不斷發展,並且正在取消某些技術限制,以便最終可以使用EF來滿足兩全其美。換句話說,最終你可以吃蛋糕並吃掉它。

希望這可以幫助。

為了回答一個關於持久性對ORM的無知是否荒謬的問題,考慮到其背後的目的是管理數據。 :-)抱歉,我無法抗拒!



Related

許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因