首先我想引用這篇文章：在MVC應用程序中將實體框架數據模型放在哪裏？具體的例子
Where to put Entity Framework Data Model in MVC application?
我的EDMX將在它7-10表。不多。
問題是我必須建立我的模型，我正在與[讓我們說] 4表。 所以我問自己：這些表是真正的模型表示，將edmx文件放在「Models」文件夾中是否正確，我應該如何命名這個CONTAINER模型？
或者10個表格足以創建一個新項目？如何調用該項目？ .DataAccess？如何命名edmx文件？
我沒有那麼多的MVC和EF經驗，我正試圖找出那裏的最佳做法。
更新：This後告訴我不要把它放在Models文件夾：「這個模型應該從後端數據存儲技術來分離儘可能。」
個人我的MVC項目（無論尺寸如何）由以下最低限度的：
這種結構似乎工作得很好的它將業務邏輯從存儲和顯示中分離出來。
您絕對不希望將EDMX放置在模型文件夾中，因爲它是爲視圖模型保留的。最佳實踐認爲，視圖模型應完全與存儲實體斷開連接。
就命名EDMX而言，我通常將它命名爲項目的短名稱，更重要的是讓EDMX的名稱空間正確，以便您的模型位於正確的命名空間位置。
我的回覆基於Silverlight，我明白它有點偏離了上下文，因爲您是從MVC的角度來問的。但請允許我說明，我把我的EDMX
-Widgets。這些都是與多個XAML頁面多個UI項目
-UI邏輯是重策劃每一個部件和一個主用戶界面
- 查看 - 模型XAML頁面。這些幾乎等同於MVC中的控制器。我使用XAML直接綁定到View-Models。示例QuotationItemModel.vb和xyz.vb等。多個XAML頁面可能共享1個虛擬機。
-XAML頁面假設按照實現視圖模型使用命令綁定。示例按鈕點擊被路由到VM。我沒有做到這一點，因爲UI協調邏輯（來自另一個UI架構師）干擾我的委託命令（CanExecute，Execute Func（Of Object，Boolean）Action（Of Object））導致第一級堆棧溢出小部件的點擊事件。）
-Model。這裏只有一個功能。她的工作將一個代理掛鉤到web服務異步調用完成事件，然後觸發web服務。 Deletegate的實現實際上回到了View-Model中，即QuotationItemModel.vb中，而不是在Model中。 Model.vb中只有一個函數 - Model中沒有其他邏輯。即Model.vb決定端點，http綁定，WCF填充
- 在此解決方案中沒有任何EDMX。模型也對數據庫一無所知。
WCF實現。重量輕。再一次功能。只有運營合同。
僅將業務對象傳入第三個項目的代碼。
EDMX的連接字符串在此處配置並傳遞給第三個項目。
沒有其他的邏輯。
沒有EDMX認識任何
-Begins用一個簡單的工廠委託邏輯和調用類
-Begins與簡單工廠的邏輯變得很沉重的後端。使用設計模式來緩解維護問題。從這裏，模式可以縱橫交錯命令，策略，或抽象類型之間的交叉等等等等
-The EDMX的設計是完全清楚，該層
- 商業對象在邏輯方式與EDMX
相互作用 - 我在這裏執行LINQ to Entities或參數化查詢
- 此層由業務邏輯組成，例如在發出索賠事務之前必須存在承保ID。或者是基於服務器日期的報價單的運行編號順序。 etc等
- 有一些業務對象到實體的手動映射。潛在的繁瑣，但並非總是
-Result傳回的XML
第三個項目，很可能是分離的溶液隔着其他輕量級web服務，生產3層架構的準備。然後我會在這個純粹的層上產生我自己的連接字符串給EDMX。但我現在更像是'2.5'二層架構。我在中間層的web配置中羞怯地暴露連接字符串。體系結構意味着完全擁有另一個硬件平臺。在問題空間即用戶界面，通信和業務領域，層是域驅動設計的分離。從技術上講，SQL Server的數據庫（超越EDMX）可以很好地坐在另一個架構上，即Windows Azure
我在這裏看到的優點和缺點。請溫和地提出任何批評，我真的是新的分層。
缺點 沒有公開數據合同，當用業務對象和合同的語言進行通信時，我的UI是盲目的。以前這很容易通過在WCF層中使用EDMX來實現。 我現在使用Xelement來表示共享業務對象。但是我仍然需要找到一種暴露數據合同而不暴露數據庫內部的方法。目前，我本能地知道並編寫我的Xelements中的數據庫字段。
這可能就像靜音綁定到後端EDMX。沉默有時是不好的，因爲如果我得到一個沒有數據的專欄，有很多懷疑的原因。沒有任何東西不能通過傳回XML結果的錯誤消息來解決。用我的想象力。
版本控制的機制很弱。也許新客戶端與單獨的操作合同進行交互，以無聲重定向到後端2.0版，而現有客戶端則利用後端版1.0。這可能意味着您現在應該分別爲每個舊數據庫和新數據庫分別使用2個EDMX
優點 極端解耦。我可以刪除/重建EDMX和UI，WCF仍然編譯。只有我的第三個解決方案會在這個極端的測試工作中遇到編譯錯誤。
從silverlight UI，觸發和與Microsoft Report Viewer報告的通信共享與UI調用的完全相同的類。無論如何，沒有「額外的報告web服務功能」。無論用戶界面要求的EDMX +邏輯完全相同 - 除非我不選擇它。 PS：Silverlight通過查詢字符串將過濾條件傳遞給報告。
該報告再次，不知道的EDMX。例如，如果我從後端刪除EDMX，然後更新報表項目中的數據連接，並且報表項目仍然編譯時沒有問題。
準備遷移到多架構而不會流淚。季節性負載平衡，客戶羣增加等可能會引發對架構的投資。
業務邏輯的可重用性。例如，如果老闆厭倦了Silverlight，我只需要將UI業務對象重新編碼爲JSON？在HTML 5之下。除了新的要求之外，對業務邏輯沒有任何改變。例如，擴展到人壽保險以與現有的一般保險共存，這是一個目前在Silverlight中編碼的模塊。在HTML 5中設想人生保險，並且仍然與相同的後端共存。同樣，原因是因爲兩個前端都不知道EDMX，我只需要關注從新技術內部構建數據合同。
意外（我是新的分層真的！）副作用。我可能可以測試我的後端與UI分開。這反過來操縱LINQ to Entity（即EDMX）。很酷的單元測試。
更新業務邏輯不影響對IIS（中間層）的新部署，除了可能涉及到版本控制時。
反正這裏離有才華的軟件架構師楊雪姬
分層架構的示例的分層應用解決方案的指導。您要下載的樣本中NET
http://layersample.codeplex.com/
http://layerguidance.codeplex.com/
通知，有過共同的後端，其中EDMX生活和睡眠在不同技術的多個UI的聰明才智。此外，在Windows工作流的基礎上，根據需要有選擇地調用。您可以看到Serena放置EDMX的位置，並且您可以在其中使用可行的運行代碼。純粹的幸福。
什麼意思是正確的命名空間位置？如果我想徹底斷開EDMX，我認爲這意味着一個獨立的項目。所以我稱這個項目爲AppName.DataAccess。所以EDMX實體將有類似AppName.DataAccess.Entities的東西。 – timmkrause 2012-03-16 11:11:32
是的，這就是我的意思，你需要確保你選擇的EDMX的名稱空間映射到AppName.DataAccess的某處，否則它不會有多大意義 – 2012-03-16 12:07:20
你可以解釋數據，邏輯和網站更深一點？我來自3層Web Forms項目（DataAccess，BusinessObjects，WebApp）。 「網站」是您的實際MVC項目嗎？而所有這些獨立的項目？ – timmkrause 2012-03-16 15:31:39