ASP.Net MVC控制器注入

我正在尋找有關設計新的ASP.NET Mvc項目的好方法的建議。它面積適中，結構相對簡單。我最初使用Spring.Net將我的服務對象連接到正確的構造函數中，但是現在管理層告訴我，Spring.Net或任何其他IOC容器都不能在我們的環境中使用。ASP.Net MVC控制器注入

我有點麻煩找出一個好的方法來設置這個沒有DI。我希望能夠以允許控制器和服務之間的低耦合度的方式將服務實現分配給控制器，並儘可能地限制控制器在各個服務實現上的可靠性。我想我的問題歸結爲，我不確定應該在MVC模型中手動連接我的應用程序。

有什麼建議嗎？

來源

2011-10-04 zaq

我很好奇爲什麼管理層決定不能使用DI？管理層爲開發者做出這種性質的技術決策是否正常？如果是這樣......運行。 – Brook

這是一個很好的問題，我不知道真的，這裏的一些其他開發商都算不上熟悉的概念，不想試一試這樣的管理已經與他們片面現在。 – zaq

會同樣限制適用於使用託管擴展框架（http://mef.codeplex.com/），因爲它是.NET的一部分？ – counsellorben

首先，我會質疑爲什麼管理層要求您不能使用一種模式和工具來實現鬆耦合和依賴注入。這是可以討論和推理的嗎？

使用IoC容器時，實現IControllerFactory的微小操作可以解決容器中的控制器並注入必要的服務。

在MVC 3中，有IDependencyResolver，您可以使用它來實現稍微寬鬆的耦合（通過Service Locator模式/反模式），而不是直接在控制器中實例化服務;這個接口被設計成與IoC容器一起使用，但它本身就是一個較差的替代品。

來源

2011-10-04 19:45:13

我看着這個並開始使用它，但似乎我最終會寫我自己的半DI容器，這是一個壞主意。我會根據你對我原來的帖子的評論，提出一個「可憐的男人DI」的建議。這仍然不是一個很好的解決方案，但我認爲這是我的限制條件下唯一的選擇。謝謝你的幫助。 – zaq

沒有probs，很高興幫助:) –

由於您使用的是ASP.NET MVC 3，因此您可以編寫一個custom dependency resolver。您當然仍會設計您的控制器在其構造函數中使用接口，以削弱層之間的耦合。然後在自定義依賴關係解析器中，爲了滿足強加於您的荒謬要求，您必須手動說明，如果您有ISomeService，則返回SomeServiceImpl的實例。你知道，對象容器和DI框架已經爲你做了什麼。所以你基本上不得不重新創造一些車輪。順便說一下，Ayende在博客上寫了一篇關於你如何能夠build a custom IoC container in 15 lines of code的博客，但當然這不是你應該這樣做的理由。

施加此類要求的人應該面臨審判並被判處永遠不必進行應用程序設計。實施這樣的要求說明了對於設計應用程序的良好實踐的一些完全缺乏知識。在他們給公司帶來進一步損害之前應該建議這些人。

所以，簡單地解釋這些人，通過重塑車輪有2個錯誤：

你會浪費很多時間的東西，已經由其他人完成
你會犯錯誤，你會不考慮設計可重用DI框架的其他人所考慮的所有邊緣情況。

在這一天結束時，你會遲到船如期您的應用程序（如你會浪費時間寫管道代碼），甚至更糟糕，你會船將包含潛在的bug的應用程序。

結論：昂貴且有問題的產品。你的管理層一定已經失去了主意:-)

結論2：使用現有的DI框架。管理層甚至不會注意到，因爲他們似乎沒有通過強加這樣的要求來理解應用程序的技術方面。

來源

2011-10-04 19:42:56

我同意你的觀點，我試圖解釋這些問題（也許我做了一個糟糕的工作，解釋它），但有一個擔心，對於其他開發者皮卡所需的時間的概念不會是值得的，它可能是很難聘請熟悉特定框架的新開發人員。 – zaq

@zaq，你認爲通過滾動自定義DI框架來浪費重新發明輪子的時間是值得的嗎？如果開發人員無法通過閱讀那裏的數百萬個教程來掌握現有DI框架的概念，那麼相信我，掌握具有定製依賴解析器的定製構建DI框架的概念將變得更加重要。 –

哦，我完全同意，但不幸的是，這不是我需要說服的。 – zaq

你的老闆有尖尖的頭髮嗎？ http://www.dilbert.com/

通過使用http://unitymvc3.codeplex.com/而不是編寫自己的自定義依賴關係解析器，您可以節省一些時間。它可以通過Nuget http://nuget.org/下載。如果你使用這樣的IOC容器，並使用構造器注入，你會發現你的單元測試更容易編寫。假設你的經理相信單元測試;-)祝你好運！

來源

2011-10-04 20:21:29 magritte

它看起來不錯，但不幸的是我已經建議Unity作爲微軟春季的替代品。 – zaq

設置和使用它非常簡單（它專門用於使用Unity和MVC3），不需要任何特殊配置，並且學習曲線對於團隊成員來說是最小的。祝你好運，聽起來像你可能需要它;-) – magritte

謝謝託尼，也許我會看看這個，然後再試一次。 – zaq

管理層告訴我，Spring.Net或任何其他國際奧委會容器是不適用於我們的環境。

管理層告訴你，你不允許編寫鬆散耦合，可測試和高維護的應用程序，這就是他們告訴你的。這是一個奇怪的限制。

依賴注入是許多開發人員不理解的高級技術。但是，管理層永遠不會理解它，理解它不是他們的工作。他們可能會決定技術的類型（例如.NET和Java），因爲這會影響他們需要聘用的人員類型，但是當他們開始對低級實施細節進行口授時，會阻止您編寫下降軟件，您的公司是走向災難。

現在就離開那家公司吧！

您的其他選項是使用Simple Injector的source code。代碼庫足夠小（大約500行，只需使用SimpleInjector.NET項目）即可將其複製到本地項目（並且許可證允許）。這樣它就是您自己的本地DI容器，但已經完全測試:-)

祝您好運。

來源

2011-10-04 20:32:23 Steven

你需要一個新家。有很多組織正在尋找關心質量和可擴展架構的優秀工程師。確保你找到合適的人，他們會很高興找到你。

避免誘惑，使您的現有團隊從他們自己的短視中解脫出來。從你的描述來看，這聽起來像你已經是一個賤民，儘管你的才能。接受你不會被傾聽的事實。

最好的策略是假裝成爲一個天生的團隊球員。建立你的MVC項目完全按照老闆的要求，即愚蠢的方式，沒有分離的擔憂。當你的項目第一版完成並通過質量保證（如果你有任何質量保證），你的老闆可能會認爲他是正確的。準備好這個反應。

對於啓發你現在的團隊成員來說，最好的希望就是向他們展示，即使你使用他們熟悉的相同的啞巴實踐來構建軟件，你仍然可以在他們周圍運行環。這可能很有趣。然後，當你離開時，你給他們一個機會去思考你是否有可能做某件事。他們可以抓住這個機會或者選擇持續的安慰，但這不再是你的問題。

來源

2011-10-05 17:13:48

ASP.Net MVC控制器注入

回答

相關問題