相关疑难解决方法(0)

我一直在使用依赖注入(DI)一段时间,在构造函数,属性或方法中注入.我从未觉得需要使用控制反转(IoC)容器.但是,我读的越多,我觉得社区使用IoC容器的压力就越大.

我使用.NET容器,如StructureMap,NInject,Unity和Funq.我仍然没有看到IoC容器如何使我的代码受益/改进.

我也害怕在工作中开始使用容器,因为我的许多同事都会看到他们不理解的代码.他们中的许多人可能不愿意学习新技术.

请说服我需要使用IoC容器.当我在工作中与开发人员交谈时,我将使用这些论点.

我正在思考一个C#库的设计,它将有几个不同的高级函数.当然,这些高级功能将尽可能使用SOLID类设计原则来实现.因此,可能存在供消费者定期直接使用的类,以及作为那些更常见的"最终用户"类的依赖性的"支持类".

问题是,设计库的最佳方法是:

• DI不可知 - 虽然为一个或两个常见的DI库(StructureMap,Ninject等)添加基本的"支持"似乎是合理的,但我希望消费者能够将该库与任何DI框架一起使用.
• 非DI可用 - 如果库的使用者没有使用DI,那么库应该仍然尽可能容易使用,减少了用户为创建所有这些"不重要"的依赖关系而必须完成的工作量.他们想要使用的"真实"类.

我目前的想法是为常见的DI库提供一些"DI注册模块"(例如,一个StructureMap注册表,一个Ninject模块),以及一个非DI的集合或工厂类,并包含与这几个工厂的耦合.

思考？

我有一个解决方案,有两个相关的(对这个问题)项目,还有一些其他项目;

1. 具有其他几个项目使用的功能的类库.
2. ASP.NET MVC应用程序.

我的问题基本上是我应该使用Ninject 2做IoC,考虑到......

• 类库需要一些DI爱,其中包括需要Web请求特定会话对象的存储库类(想想工作单元).
• MVC应用程序需要DI,因为在Ninject 2中你基本上都是从NinjectHttpApplication继承的.
• 类库的单元测试需要注意这一点,以注入一组不同的存储库.
• 出于同样的原因,需要注入Web应用程序的单元测试.

我把自己画成了一个心理角落,因为我只看到了三个选项.类库中的DI,Web应用程序中的DI,或两者都有,但每个都有问题:

• 我不能只在类库中做DI ,因为MVC应用程序需要从NinjectHttpApplication继承而开始.
• 我不能只在MVC应用程序中执行DI - 毕竟,类库是由其他库使用的,并且MVC应用程序不应该对库的内部结构有太多了解.
• 我想这是我能看到的唯一出路:两个项目的独立IoC.类库和MVC应用程序都有自己的IoC设置,并为他们的东西做DI,而不是真正关心彼此.

有没有人对如何做这样的事情有一些"最佳实践"或指导方针？我无法想象我是第一个在这种情况下结束的人,而且知道"正确"的做法是什么肯定会很好......

谢谢!