.NET項目/命名空間組織問題

Question

我們有一個框架定義了許多接口和一些基本的默認實現。我們稱之爲CompanyFramework。我有一些ASP.NET MVC擴展，目前存儲在一個單獨的項目CompanyFramework.Web.Mvc中。原因是，使用核心框架但與MVC無關的應用程序無需引用ASP.NET MVC庫。我不太喜歡這種設置，因爲額外的程序集只包含3-4個類文件，但它是避免向主框架程序集引入不必要的依賴關係的最簡單方法。

現在，我們有一些用於ASP.NET MVC的特定於StructureMap的擴展，即自定義控制器工廠和模型綁定器類型的東西。你會把這樣的東西放在哪裏？我可以把它放在CompanyFramework.Web.Mvc項目中，但是任何使用它的ASP.NET MVC項目都會引用StructureMap程序集，即使它沒有被使用。我也可以創建一個單獨的CompanyFramework.StructureMap項目，但如果我曾經開發任何不依賴於ASP.NET MVC的StructureMap的擴展，我仍然很喜歡爲使用它們的類引用MVC程序集。

我應該做一個單獨的CompanyFramework.Web.Mvc.StructureMap項目嗎？這種方法總體上看起來最乾淨，但我覺得我正在開始引入一堆混亂整個項目結構的輕量級衛星組件。

Answer 1

對於任何這樣的問題，我發現考慮未來修改決定的長期影響是有幫助的。最終，這些圖書館中的一部分將被廢棄並被取代，而另一些將繼續生存下去。例如，一些技術將會取代MVC。

我相信將這些東西分開將使未來的開發人員和維護人員的生活變得容易很多。依賴關係將更加明確（這總是一件好事），遷移決策可以更加自信和清晰。

此外，一個不斷擴大的泥漿大球庫不是你想要在未來的每一個項目上因其他原因而需要處理的東西。 「一堆輕便的組件」聽起來像是我設計的一個優秀目標。

Answer 2

更糟糕的是，糟糕的依賴或少量的額外項目？一個稍微混亂的IDE是一個很好的定義結構的小价格。

Answer 3

我建議將StructureMap與MVC項目結合使用。我認爲這在邏輯上是最有意義的，並且在某些情況下使用未使用的參考不會成爲問題。

我認爲你目前的設置（CompanyFramework程序集+ MVC程序集）是非常合理的。我發現我最終會遵循相同的模式：一個常見的程序集，一個Web程序集（或專門針對MVC或Web表單），一個數據庫程序集等。在這樣的高級功能級別上分離它們是好的地方開始。