我不知道，如果倉庫圖案僅僅是我看到的最常見的東西，或者如果它是抽象的數據庫和控制器之間的層的最佳實踐。今天發現了一些很好的資源解釋持久性的無知以及爲什麼它對單元測試有好處。不過，我仍然不清楚適當的實體框架實施。實體框架模型第倉庫混亂
我當前的項目，我去一下先創建模型。我可以肯定地說，我的總根源是：
這些根是相當豐富的引用「查找實體」，在模型。也就是說，我的模型包含20個奇怪的實體，其中一些主要用於查找目的。如果我要實施存儲庫模式，
我是否需要創建一個POCO爲每個實體？ 對於模型中的大多數實體，您應該有一個普通的舊CLR對象。您還應該爲每個複雜類型（ddd中的值對象）提供一個POCO。您可能不希望實體的POCO的情況是爲m..n關係創建動名類型時。您可以在EF 4.1中爲這些POCO創建POCO，但您不必這樣做。
我曾經引用自動生成的EF類/ entites的作爲存儲庫的屬性？ 唯一自動生成的EF類/據我所知，在EF 4.1代碼實體第一種是在運行時創建來填充您的導航和集合屬性的動態代理。你不能也不應該試圖在你的任何源代碼中引用它們。哦，我想你可能會混淆術語「屬性」。屬性是特殊的類，可以用來裝飾類和方法。在這個意義上，實體類不能用作屬性。
我是否總是需要在與實體框架進行交互時使用存儲庫？ 不。實際上很多人都說你不應該創建一個存儲庫，直到你發現你需要一個存儲庫。但是如果你通過單元測試來推動你的開發，你會發現需要一個倉庫界面。
在實體框架，您的DataContext類是版本庫，以及一個在你有很多與EF 4.1控制。我不以任何方式表達惡意，因爲這是一個非常好的問題，有很多不好的答案。
當您使用EF，你已經在使用存儲庫模式。利用這一點，並減少代碼。抵制過度建築的衝動。
1）這取決於您的行爲模型（您的對象）如何轉換爲您的數據模型（您的數據庫）。沒有任何規範性指導。
2）EF已經做到了這一點，如果屬性指的是屬性。
3）你已經做到了。 :-)
斯蒂芬
我必須非常不同意EF是一個存儲庫模式，因爲您不能單元測試並將自己的數據注入到它中 - 它需要連接到數據庫。它絕對是一個UnitOfWork模式，它就像一個存儲庫模式。但是，如果不將它們包裝到界面中，則無法模擬您的IDbSet屬性。 – danludwig 2011-12-20 12:11:14
我用模型代替第一代碼先去了。儘管看起來這是無關緊要的。所以我收集的是我在.edmx文件中創建的實體實際上是代理？而且我應該爲這些每個創建POCO。我正在嘗試在TDD之後執行此項目。 – Michael 2011-12-20 16:33:50
我建議你稍微休息一下，如果可以的話，至少要先查看代碼。它實際上是模型優先的，但是您可以從類構建實體模型而不是edmx設計表面。然後EF 4.1將爲您生成數據庫模式。它使用默認約定，但您可以將它們更改爲在數據庫中雕刻不同的模式。對不起，我不能提供很多幫助，因爲我不再使用edmx文件。 – danludwig 2011-12-20 16:49:14
好的。所以我們假設我將重構代碼優先實現。我創建了我的POCO的第一個。我先看過幾個代碼示例，然後看到兩個不同的東西。使用DbContext和使用對象上下文來實現上下文。什麼是選擇一個在另一個之上的一些論據。我覺得這裏有一些神奇的事情發生在這裏，不使用edmx來生成數據庫模式。代碼優先方法如何生成模式？ – Michael 2011-12-20 17:06:44