ASP.Net MVC控制器注入
我正在寻找有关设计新的ASP.NET Mvc项目的好方法的建议。它面积适中，结构相对简单。我最初使用Spring.Net将我的服务对象连接到正确的构造函数中，但是现在管理层告诉我，Spring.Net或任何其他IOC容器都不能在我们的环境中使用。ASP.Net MVC控制器注入
我有点麻烦找出一个好的方法来设置这个没有DI。我希望能够以允许控制器和服务之间的低耦合度的方式将服务实现分配给控制器，并尽可能地限制控制器在各个服务实现上的可靠性。我想我的问题归结为，我不确定应该在MVC模型中手动连接我的应用程序。
有什么建议吗？
首先，我会质疑为什么管理层要求您不能使用一种模式和工具来实现松耦合和依赖注入。这是可以讨论和推理的吗？
使用IoC容器时，实现IControllerFactory的微小操作可以解决容器中的控制器并注入必要的服务。
在MVC 3中，有IDependencyResolver，您可以使用它来实现稍微宽松的耦合（通过Service Locator模式/反模式），而不是直接在控制器中实例化服务;这个接口被设计成与IoC容器一起使用，但它本身就是一个较差的替代品。
我看着这个并开始使用它，但似乎我最终会写我自己的半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框架。管理层甚至不会注意到，因为他们似乎没有通过强加这样的要求来理解应用程序的技术方面。
你的老板有尖尖的头发吗？ http://www.dilbert.com/
通过使用http://unitymvc3.codeplex.com/而不是编写自己的自定义依赖关系解析器，您可以节省一些时间。它可以通过Nuget http://nuget.org/下载。如果你使用这样的IOC容器，并使用构造器注入，你会发现你的单元测试更容易编写。假设你的经理相信单元测试;-)祝你好运！
管理层告诉我，Spring.Net或任何其他国际奥委会容器是 不适用于我们的环境。
管理层告诉你，你不允许编写松散耦合，可测试和高维护的应用程序，这就是他们告诉你的。这是一个奇怪的限制。
依赖注入是许多开发人员不理解的高级技术。但是，管理层永远不会理解它，理解它不是他们的工作。他们可能会决定技术的类型（例如.NET和Java），因为这会影响他们需要聘用的人员类型，但是当他们开始对低级实施细节进行口授时，会阻止您编写下降软件，您的公司是走向灾难。
现在就离开那家公司吧！
您的其他选项是使用Simple Injector的source code。代码库足够小（大约500行，只需使用SimpleInjector.NET项目）即可将其复制到本地项目（并且许可证允许）。这样它就是您自己的本地DI容器，但已经完全测试:-)
祝您好运。
你需要一个新家。有很多组织正在寻找关心质量和可扩展架构的优秀工程师。确保你找到合适的人，他们会很高兴找到你。
避免诱惑，使您的现有团队从他们自己的短视中解脱出来。从你的描述来看，这听起来像你已经是一个贱民，尽管你的才能。接受你不会被倾听的事实。
最好的策略是假装成为一个天生的团队球员。建立你的MVC项目完全按照老板的要求，即愚蠢的方式，没有分离的担忧。当你的项目第一版完成并通过质量保证（如果你有任何质量保证），你的老板可能会认为他是正确的。准备好这个反应。
对于启发你现在的团队成员来说，最好的希望就是向他们展示，即使你使用他们熟悉的相同的哑巴实践来构建软件，你仍然可以在他们周围运行环。这可能很有趣。然后，当你离开时，你给他们一个机会去思考你是否有可能做某件事。他们可以抓住这个机会或者选择持续的安慰，但这不再是你的问题。
我很好奇为什么管理层决定不能使用DI？管理层为开发者做出这种性质的技术决策是否正常？如果是这样......运行。 – Brook
这是一个很好的问题，我不知道真的，这里的一些其他开发商都算不上熟悉的概念，不想试一试这样的管理已经与他们片面现在。 – zaq
会同样限制适用于使用托管扩展框架（http://mef.codeplex.com/），因为它是.NET的一部分？ – counsellorben