使用區域來構建一個大的Asp.net MVC應用程序是不錯的選擇嗎？

Question

每個區域都有自己的配置等，隨着區域的增加，複雜性和可維護性也隨之增加。將模塊化或分區和MVC應用程序功能集成到區域，還是繼續使用傳統的控制器/視圖方法，將會是不錯的選擇？

請提出一個通用的解決方案或更好的方法來構建大規模的MVC應用程序。

Answer 1

區域不應該混淆，並且肯定不是多餘的。正如你所說，他們允許你將你的網絡應用分成更小的功能分組。當您的應用程序規模增長並且單個應用程序變得笨拙時，這非常有用。

作爲一個例子，我剛剛完成了一個大型應用程序，用於存儲北美各個零售商的促銷數據。美國和加拿大的銷售團隊是孤立的，但在幾乎相同的業務環境中執行他們的任務。

將網絡應用程序的美國和加拿大部分劃分爲多個區域，這對我們來說組織起來有很大幫助。每個區域仍然可以使用相同的組件（存儲庫，服務等），但隔離區帶來的幫助我們可以針對每個業務組構建單獨的控制器和視圖，而不是試圖運行一堆邏輯檢查，以適應用戶在任何區域

Answer 2

這是可能的選擇從「編程ASP.NET MVC 4」由傑西·查德威克，託德·斯奈德和Hrusikesh熊貓你的方法：

有設計ASP.NET MVC應用程序時採用了許多不同的方法。開發人員可以決定將所有應用程序的 組件保留在網站程序集內，或者將組件分離爲不同的程序集。在大多數情況下，將 業務層和數據訪問層分成不同的部件是一個好主意，而不是 網站。這通常是爲了更好地隔離用戶界面中的業務模型 ，並使編寫自動化測試更加容易，該測試着重於核心應用程序邏輯 。另外，使用這種方法可以重用 應用程序（控制檯應用程序，網站，Web服務等）的業務層和數據訪問層。

通用根名稱空間（例如，公司。{ApplicationName}）應始終在所有組件中始終使用 。每個程序集應該有一個 與程序集名稱相匹配的唯一子名稱空間。圖5-4 顯示了Ebuy參考應用程序的項目結構。該應用程序的 功能已被劃分爲三個 項目：Ebuy.WebSite包含視圖，控制器和其他 與Web相關的文件; Ebuy.Core包含 應用程序的商業模式;而CustomExtentions項目包含應用程序用於模型綁定，路由和控制器的定製 擴展。此外，該項目還有兩個測試項目（不是 顯示）：UnitTests和IntegrationTests。

Answer 3

有對是否使用區域或沒有任何規則，它基本上可達解決方案架構師做一個估計應該使用地區提供的利益或沒有。

我們涉及領域的最新項目包括3個不同類型的用戶在網站上工作。我們使用控制器命名方案，其中控制器名稱與資源名稱（即CategoryController）相匹配。但是，某些資源可能已經以完全不同的方式被所有3個用戶組訪問：一個用戶組只能列出資源，其他用戶組可以管理它們（基本crud），而第三個用戶組（管理員）可以執行高級功能，例如導出，導入等......

通過分離區域中的功能，我們通過簡單地裝飾區域中的控制器以請求該區域的特定用戶類型來減少安全問題，以便避免混合權限。在該地區的基礎控制器上進行操作，使事情更加集中。

這就是我們選擇區域分離的原因之一。

另一方面，我們經常處於需要高要求公共網站和「後臺」內部配置網站的情況。對於性能和可伸縮性+併發性問題，我們經常設計可作爲單項目進行負載平衡的公共網站，以及僅作爲第二個項目託管一次的後臺網站 - 而不是使用區域。

再次，這只是行業的一種方法，不一定是最佳方法。