實體框架4.1的生成器的困惑

我正在評估一個項目的實體框架與傳統數據庫。該數據庫設計得非常好，並且已經決定使用數據庫優先方法。該應用程序將基於WinForms，但我希望提前計劃並考慮ASP.Net以及它可能會在某個時間點被管理請求，我想重用DAL。實體框架4.1的生成器的困惑

現在，我的理解是實體框架提供了多種方式爲實體對象中產生：從EntityObject

POCO（ObjectContext中）

POCO（的DbContext）

自我衍生

對象跟蹤實體（STE）

我一直在試圖比較這三種方法，直到目前爲止。

EntityObject T4模板是其中最富有的。例如，它將來自實體模型的註釋放置在每個類的頂部和實體的每個屬性的XMLDoc註釋中，這在代碼可維護性方面相當不錯並且有用。沒有其他的生成器支持這種開箱即使（雖然我知道可以修改T4模板，但它顯然需要一些工作）。另一方面，DbContext API更好一些。

EntityObject派生類型提供了一個事件，您可以在實體屬性更改時掛鉤，這對實現業務邏輯很有用。

我知道POCO對此更自然，但是T4生成器會在每次模型更改時覆蓋我所做的所有更改。當然，生成的POCO是部分類，但據我所知，不可能覆蓋已經在部分類中定義的屬性，所以我不確定在它們中實現業務邏輯是如何完成的？

許多人似乎討厭EntityObject派生類，更喜歡使用POCO方法，但它似乎損失了很多EntityObjects開箱即用的功能， POCO路線。考慮到對POCO對象的普遍偏好，我可能會誤解某些東西，因此我的問題。

最後，哪種生成器最適合ASP.Net環境？我擔心我的實體更改會停止跟蹤？自我跟蹤實體在這種情況下更有用，還是他們只對Web服務有價值（我可能不會使用）？

非常感謝提前。

來源

2011-10-11 Kharlos Dominguez

如果你想使用EF 4.1，你的選項只有DbContext Generator。所有其他生成器（POCO，EntityObject和STE）都用於ObejctContext API（EF 4.0）。我描述了發電機here之間的差異。

在你的情況下，EntityObject生成器可用於WinForms，但對於ASP.NET解決方案而言，由於ASP.NET應用程序處於分離狀態，所以POCO更好，這樣會很麻煩 - 無論如何，您將不得不處理ASP.NET中的更改跟蹤。

STE的目的描述爲here但它們在WinForm中並不是非常有用，您可以直接使用附加實體，或者在視圖狀態請求之間使用demands to store them的ASP.NET。

要直接放入實體的任何業務邏輯都必須在T4生成器中編碼，否則它將在每代生成後被覆蓋。您提到的基於EntityObject的每個功能都可以在POCO/DbContext生成器中實現。

來源

2011-10-11 12:20:38

謝謝。這很有幫助。通過「你想直接放入實體的任何業務邏輯必須在T4生成器中編碼」，你的意思是我需要修改T4模板，以便生成類似於EntityObjects的On [Property] Changed的事件？我對T4做了一些改變，我不能說這是一種有趣的體驗。考慮到這一點，我很驚訝沒有看到更多的EF T4腳本，但只有MS-ones。另外，我擔心這些事件可能不會在ASP.Net環境中引發，他們會（當數據被髮回服務器時）嗎？ –

「你想直接放入實體的任何業務邏輯必須在T4生成器中編碼，否則它將在每一代之後被覆蓋」<----這是不正確的。您需要將業務邏輯放在一個**分開的**部分類文件中，並且它將保留而沒有任何問題。上面的所有生成器都已經生成了部分類。 – Bobson

@Bobson：你看過這個問題嗎？我們正在討論生成屬性中的其他邏輯。仍然存在部分課程或部分方法不起作用的情況。 –

實體框架4.1的生成器的困惑

回答

相關問題