2012-03-25 48 views
6

我的團隊計劃在今年6月份啓動一個新項目。該應用程序傾向於由2,000個併發用戶使用。現在我們正在討論技術決策 - 我們將在我們的項目中使用的IoC容器。我的團隊中的所有成員都沒有IoC經驗,我們中的一些人閱讀並瞭解它是什麼。我們的要求是:用於中型ASP.NET MVC的.NET IoC容器

  1. 性能 - 我們的管理狀態的IoC可能減慢應用程序,他們希望我們使用IoC容器也不會降低性能。他們還希望IoC容器在小型或大型或解決方案過程中具有良好的性能。
  2. 功能集 - 我的同事們期望它具有豐富的功能集。目前我不知道我們會使用哪些功能,但是我有經驗,有些組件可以輕鬆啓動,但無法做更多事情。
  3. 文檔或書籍 - 我計劃通過閱讀在線文檔或書籍來研究我們選擇的IoC。
  4. 與ASP.NET MVC 4
+1

請檢查http://stackoverflow.com/questions/1140730/net-ioc-container-comparisons。同樣,在選擇IoC容器時,確保可以使用它,而不會在代碼中留下太多佔用空間。 – Chandermani 2012-03-26 05:32:06

+0

@Chandermani感謝您的鏈接。我讀到了這個問題,但幾乎在三年前問過了。我不確定,它是否過時? – Anonymous 2012-03-26 15:45:07

+2

請參閱http://www.iocbattle.com/和git測試工具,您可以自己對更新的IoC容器進行基準測試。也從SO讀這篇帖子。這傢伙回答了最好的問題http://stackoverflow.com/questions/5315562/di-ioc-container-performance-benchmark-comparison – Chandermani 2012-03-26 17:00:06

回答

7

我用StructureMap,Autofac和Ninject工作。他們都很好。

我建議使用CommonServiceLocator [http://commonservicelocator.codeplex.com]作爲您的實施的一部分。這樣以後很容易改變主意。

我個人比較喜歡Autofac最好。它具有功能和簡單性的良好平衡。

  • 支持自動裝配和組裝掃描
  • 壽命範圍設定(如單件或HttpRequest的)
  • 易於註冊到
  • 支持命名或鍵控(由枚舉命名)的多個請求類型的註冊
  • 的實施
  • 它的快速

http://code.google.com/p/autofac/wiki/MvcIntegration http://nuget.org/packages/Autofac.CommonServiceLocator-unofficial

+0

由於誰投票拒絕了你不禮貌地說出原因,我打算猜測這是因爲Common Service Locator在這裏被認爲是一種反模式,也就是糟糕的做法。 – 2012-09-10 19:11:11

+0

我不明白爲什麼CommonServiceLocator是一個壞主意,因爲所問的問題是關於MVC項目中的IoC容器。 DependencyResolver.SetResolver方法甚至接受CommonServiceLocator作爲重載方法之一。 – 2012-09-15 18:21:03

+0

這是一個不好的做法,因爲它使用任何容器到最低公分母。您失去了容器提供的許多特殊功能。 – 2013-11-15 21:06:48