我有一种情况,我目前正在为一个适合更大 Web 框架的小模块使用构造函数依赖注入。
它工作正常,但现在引入了一个需要传递 2 个对象的新类。但是,其中 1 个对象需要大量工作才能设置 - 本质上它涉及 4 个方法调用,这些方法调用创建其他对象以使其进入准备好传递给我的对象的工作状态。
我的困境是由于所涉及的工作,构造函数注入没有用,但是引入 ioc 容器太过分了,尤其是对于这个 1 off 用例。
那么,这应该如何处理呢?在这两个选项中间是否有某种解决方案?
我有一种情况,我目前正在为一个适合更大 Web 框架的小模块使用构造函数依赖注入。
它工作正常,但现在引入了一个需要传递 2 个对象的新类。但是,其中 1 个对象需要大量工作才能设置 - 本质上它涉及 4 个方法调用,这些方法调用创建其他对象以使其进入准备好传递给我的对象的工作状态。
我的困境是由于所涉及的工作,构造函数注入没有用,但是引入 ioc 容器太过分了,尤其是对于这个 1 off 用例。
那么,这应该如何处理呢?在这两个选项中间是否有某种解决方案?
您实际上有四个五个选择:
我通常从 IoC 容器开始,但我做了很多DI。(我见过太多紧密耦合的代码库。)
如果您不想引入 IoC 容器,我会倾向于Poor Man's DI。
如果您使用任何面向对象的语言(不仅仅是 C#),我建议您阅读.NET 中的依赖注入一书。它详细介绍了模式和反模式。
其中 1 个对象需要大量工作才能设置 - 基本上它涉及 4 个方法调用,这些方法调用创建其他对象以使其进入准备好传递给我的对象的工作状态。
OK,接下来创建对象并将完全初始化的对象传递给构造函数,它需要去的地方。
创建该对象听起来像是 Builder 或 Factory 的工作。
我的困境是由于所涉及的工作,构造函数注入没有用,
我更喜欢Constructor Injection
并且没有理由避免它。
使用现代 IoC 框架,您可以通过工厂/工厂方法指定涉及“设置大量工作”的创建逻辑。
无论构建 的实例需要多少步骤IMyService
,您都可以简单地使用构造函数依赖项来注入它。
container.AddFacility<FactorySupportFacility>()
.Register(
Component.For<IMyFactory>().ImplementedBy<MyFactory>(),
Component.For<IMyService>()
.UsingFactoryMethod(k => k.Resolve<IMyFactory>().Create())
);
var container = new UnityContainer();
container.RegisterType<IMyFactory, MyFactory>();
container.RegisterType<IMyService>(
new InjectionFactory(c => c.Resolve<IMyFactory>().Create()));