3 回答
TA贡献1898条经验 获得超8个赞
<2美分>
如果您以后决定使用需要更多或更少的服务而不只是上下文,该怎么办?
构造函数参数和IoC的问题在于,这些参数最终会与所使用的具体类型相关联,而不是成为服务接口定义的合同的一部分。
我的建议是,您也可以解析上下文,并且我相信Unity应该为您提供一种避免构造它的3个实例的方法,或者您应该考虑一种可以为您构造对象的工厂服务。
例如,如果您以后决定构建一个完全不依赖传统数据库的存储库,而是使用XML文件为测试生成伪数据该怎么办?您将如何向该构造函数提供XML内容?
IoC基于解耦代码,通过将参数的类型和参数的语义绑定到具体类型,您确实没有正确地进行解耦,仍然存在依赖性。
“只要实现此接口,此代码就可以与任何类型的存储库进行对话。...哦,并使用数据上下文”。
现在,我知道其他IoC容器也对此提供支持,我在自己的第一个版本中也对此提供了支持,但我认为它不属于解决步骤。
</ 2美分>
TA贡献1825条经验 获得超4个赞
您可以根据您的注入架构在ResolvedParameter <T>(“ name”)中使用InjectionConstructor / InjectionProperty / InjectionMethod来获取容器中预注册对象的实例。
在您的情况下,此对象必须使用名称注册,并且为同样起见,您需要ContainerControlledLifeTimeManager()与LifeTimeManager。
_unityContainer.RegisterType<IDataContext,DataContextA>("DataContextA", new ContainerControlledLifeTimeManager());
_unityContainer.RegisterType<IDataContext,DataContextB>("DataContextB");
var repositoryA = _unityContainer.Resolve<IRepositoryA>(new InjectionConstructor(
new ResolvedParameter<IDataContext>("DataContextA")));
var repositoryB = _unityContainer.Resolve<IRepositoryB>(new InjectionConstructor(
new ResolvedParameter<IDataContext>("DataContextA")));
var repositoryA2 = _unityContainer.Resolve<IRepositoryA>(new InjectionConstructor(
new ResolvedParameter<IDataContext>("DataContextB")));
- 3 回答
- 0 关注
- 702 浏览
添加回答
举报