使用依賴注入來組織ASP.Net MVC解決方案的最佳方式是什麼？

我很早就開發一個新的ASP.Net MVC項目，我正在使用這個項目進入DI。我非常肯定，我會去結構圖，但這不是我所問的。我想弄清楚的是如何最好地組織我的解決方案。單元測試項目和模型都得到一個配置文件來映射它們的依賴關係，還是有一個類來統治它們？使用依賴注入來組織ASP.Net MVC解決方案的最佳方式是什麼？

另外，有沒有新手陷阱要避免在我陷入太深之前？

非常感謝，所有.....

更新我要補充一點，當我說「組織的解決方案」，我指的不是文件/文件夾等的數量，而是如何構建與DI有關的類。特別是如何管理引導程序。我可以看到我的部分可能會引起混淆。

來源

2009-06-08 KevDog

我的帶StructureMap的新手陷阱是中等信任下的安全權限例外。如果您的應用程序將在中等信任環境中運行，您將需要查看備用DI容器。 – 2009-06-08 03:24:28

鼓勵更好的TDD。有兩個測試項目和或名稱域X.Unit.Tests & X.Integrations.Tests。

我在我的主項目中的「名稱空間目錄」（/ Config）中有我的DI代碼，但在集成代碼測試中，我可能只需調用這些註冊表即可，或者如果我在我的基礎設備或設置中需要，

E.g.

/Config/ServiceRegistry.cs /Config/RepositoryRegistry.cs /Config/Bootstrapper.cs

在Global.asax中我叫Bootstrapper.Init（），這將調用x.AddRegistry（新ServiceRegistry（））等等。

在我的單元測試中，您不需要僅在集成測試中使用DI。在我的IntegrationTests中，例如如果我通過數據庫測試NHibernate，我可能會用TestSetUp中的RepositoryRegistry用一個只包裝GetInstance（）的輔助方法初始化SM。

我沒有拆分項目.Bootstraper和.Domain，直到我絕對必須...三個項目，X，X.UnitTests，X.Integration，如果你以後需要更多的移動。我來自背景/公司強制執行的幾十個項目，感覺骯髒是第一次減少，但不是現在，我很快就開始增長運行，並在需要時重新組織解決方案結構。

來源

2009-07-22 10:59:11

如果你是唯一一個在項目上工作的人，我會做你首先對你有意義。沒有什麼比施加目錄或項目結構更糟糕的是你覺得不直觀。 \ Core \文件夾或\ Controller \文件夾中的BaseController類是什麼？就個人而言，我會看看控制器，但有些人發誓它應該在\ Core \或\ Bases中。

第一個新手陷阱認爲您可以以錯誤的方式組織您的代碼，並以某種方式反映了項目的成功。我見過有30個文件在一個文件夾中的項目，以及其他30個文件夾中有20個文件夾的項目。

第二個新手陷阱忘記了與其他語言相比，您擁有真棒智能感知，代碼導航工具和Visual Studio重構支持的優勢。你也有一個編譯器，它會讓文件放錯位置而不那麼痛苦。如果你把某些東西放在「錯誤」的地方，那麼你可以隨時找到它並將它拖到需要的地方。

我會說實話我現在正在做一個項目，我甚至不知道某些類在我的文件結構中的位置。轉到定義/聲明是我使用很多的鍵盤快捷鍵。因爲只有我用代碼工作，這很好。如果我不得不在項目中添加另一個開發人員，我可能會清理乾淨。

我個人傾向於將Interfaces與它們的實現類型放在同一個文件夾中。 IPaymentGateway與AuthorizeNetGateway和PaypalGateway位於同一個文件夾中。如果我無法一次在我的解決方案資源管理器側欄中查看該文件夾中的所有文件，那麼我將所有網關文件移動到\ Gateway \文件夾中。

隨着依賴注入添加到混音我建議你只關心命名空間爆炸。你可以做的最糟糕的事情是用很長的聲明和別名處理引導程序和文件。

ForRequestedType<Customer>

是清潔比

using KevDog.Models 
using Customer=KevDog.Models.Customer

或

ForRequestedType<KevDog.Models.Customer>

另一種方式來避免這個問題是要明確的，當你命名的東西：客戶，CustomerViewModel，CustomerController，CustomerDataRow，CustomerView

對於TDD，您幾乎必須有兩個引導程序來管理你的具體類型。你真的不希望你的單元測試使用AuthorizeNetGateway：IPaymentGateway，而是StubGateway：IPaymentGateway。

現在我也是DI的新手，所以我傾向於使事情變得非常簡單，並反映101級別的教程和文檔。只有在特定情況需要時才能使用基於構建配置的動態注入，並且您確切知道自己爲什麼要這樣做。

我通常也保留MVC應用程序的默認結構。只需要99％的所有教程和視頻，就可以更容易地使您的代碼具有相同的結構。

希望這會有所幫助。

來源

2009-06-08 03:30:57 jfar

謝謝jfar！關於TDD的評論真的是我想問的那種東西。我認爲每個項目的引導程序的想法是要走的路。一個在單元測試項目中，另一個在MVC項目中 – KevDog 2009-06-08 14:12:39

這是我第一次嘗試爲自己解決同樣的問題，但由於這是我第一次嘗試，我希望人們可以評論或批評它，儘可能多地我希望它可以作爲一種可能的解決方案你：

public VatManager() 
: this(new VatManagerRegistry()) { } 

public VatManager(Registry registry) 
: this(new Action<IInitializationExpression>(x => { x.AddRegistry(registry); })) 
    { 
    } 

public VatManager(Action<IInitializationExpression> action) 
    { 
    ObjectFactory.Initialize(action); 
    data = ObjectFactory.GetInstance<IVatManagerData>(); 
    }

我有三個構造函數重載 - 無參數的默認構造函數是，需要在生產環境中使用要創建的具體StructureMap登記的知識。另外兩個允許實例化這個管理器類的其他代碼提供它們自己的StructureMap註冊表或動作，以便它們可以自己控制依賴注入，例如在提供模擬的自動化測試的情況下代替那些具體實例依賴。我應該補充說，這個解決方案不是特定於ASP.NET MVC上下文，也不會從* .config文件中提取任何配置信息。

來源

2010-06-18 17:54:36

使用依賴注入來組織ASP.Net MVC解決方案的最佳方式是什麼？

回答

相關問題