關於ASP.NET MVC應用程序結構的建議

Question

我是一位正在向C＃世界過渡的Java開發人員。我已經對ASP.NET MVC有了很好的處理（並且可以將它與我爲Struts學到的概念進行比較/對比）。

但是，我正在尋找關於如何構建我的項目的建議。目前，我在這個項目中有兩個解決方案：MVC Web應用程序和一個ClassLibrary部分。

該應用程序使用分層架構：控制器/服務/ DAO。爲了讓事情「正確」工作，我在MVC解決方案中有Controller和Model類，在ClassLibrary解決方案中有Services，DAO和Security。不幸的是，這導致了各種小問題（例如：當我試圖在MVC端進行表單驗證時，將ClassAibrary對象從實體框架擴展到ClassLibrary端時是不明確的）。

我唯一能提出的解決方案是將所有東西放入MVC項目中，並組織App_Code文件夾下的ClassLibrary中的內容。它會解決一些問題，但對我來說似乎是「錯誤的」;我的Java項目將代碼分隔成一個src目錄，並將視圖（jsp）分離到ta webapp目錄中。

一些更有經驗的.NET開發人員會怎麼想？

Answer 1

通常在.NET解決方案中，最好的辦法是將代碼分離到不同的項目中，但前提是該代碼可能對其他應用程序有用，或者代碼本身代表某個問題域的完整解決方案。僅由一個應用程序項目引用的類庫是浪費。

另外，請記住，.NET不允許在兩個不同程序集（通常與項目一對一轉換）中的對象之間循環引用。

在你的例子中，我建議你考慮模型，服務和安全性的一個類庫......這取決於你說「服務」時的意思。

在大多數情況下，數據訪問與MVC模型的概念有些耦合，因此您可能會考慮將數據訪問也放在那裏......但是如果您有一個非常乾淨的獨立數據訪問層，它可能適合它是自己的類庫。

控制器和視圖一般應直接進入Web項目。

一般來說，我的建議是隻有當你有一個實際的「需要」這樣做時，才能將東西分成單獨的項目。但是程序集和項目並不是在大多數應用程序中表示圖層或層的好方法。這些邏輯概念並不總是很好地映射到物理項目結構上。如果你真的很好地設計你的實際類並避免緊密耦合，那麼如果確實會出現真正令人信服的需求，通常可以將代碼移入類庫中。

Answer 2

通過使事情「正確」工作意味着什麼？我發現大多數問題都可以通過在web.config的命名空間導入部分簡單包含命名空間來解決。當你這樣做時，來自其他程序集的模型會自動解析並顯示在MVC對話框中，而在編碼視圖時會顯示在intellisense中。