我在「模型」文件夾中看到了一些使用Entity Framework DataContext類的項目，但由於它不是一個真正的模型，所以這不太合適。在ASP.NET MVC中，放置我的Entity-Framework DataContext類的「最佳實踐」位置（文件夾）在哪裏？
目前我的DataContext（和IDatabaseInitializer類一起）存在於我的項目的根目錄中，但也讓我感到困惑。
有沒有一個常見的/最佳做法，或者我應該把它們留在根或稱爲數據或文件夾？
可以說它是是該模型，因爲它維護你的應用程序的狀態。這就是人們把它放在那裏的原因。
如果你是一個好孩子，並使用抽象/存儲庫層 - 它應該去那裏。
如果您的控制器正在直接與EF上下文（壞主意）交談，然後將其放入模型文件夾 - 無需物理隱藏您的邏輯上不抽象的東西。
在其他地方我工作，VS解決方案被分成3個項目：（業務邏輯類INC POCO實體）
這是一個很好的觀點 - 儘管對於微不足道的小型網絡應用程序來說，這可能有點矯枉過正:-) – 2011-05-18 09:36:37
對於小的東西，我通常會把它放在一個'Data'或'Classes \ Data'文件夾中。 – 2011-05-18 09:38:02
沒關係。我把它放在Models文件夾中，因爲這是所有數據庫的東西進入。
使用我們的數據存儲庫創建不同的項目，將項目添加到解決方案並在需要時引用它。存儲庫模式可以根據需要爲功能測試和更改數據層。
在該示例中，存儲庫只是一個一對一映射。對於這麼簡單的事情來說，這對我來說就像是過度工程。 – 2011-05-18 10:51:27
我會說，它的最佳實踐把它放在模型，因爲它是MVC模型來描述和我一直在努力爲MVC過去3個月，我非常贊成將這個...加上它給你很大的靈活性，當調用EM類...
只是我的想法;對於與實體框架相關的任何類，例如DataContext類或Base類，我們將它們放在DataFramework文件夾中。在理論上，雖然它們在這種情況下擴展了EntityFramework，但沒有理由不能擴展其他數據庫框架，如nHibernate。
我正在開發的項目非常簡單，將EF上下文抽象出來只會導致一對一地包裝上下文的屬性/方法，所以在這種情況下，這樣做可能會過度。 – 2011-05-18 10:27:46
實際上，一個映射通常是一個糟糕的體系結構和貧血域模型的標誌。但是，如果你在一個簡單的項目上工作，控制器直接使用ctx，然後把它放在models文件夾中，或者創建一個數據文件夾。 – RPM1984 2011-05-18 10:36:53
我並不真正理解爲什麼這暗示了一個貧血域模型，也不知道如何避免一對一的包裝，當所有的訪問幾乎完全是「從e.db中的e.Field = value」的形式：/ – 2011-05-18 10:46:59