我工作中的应用是依靠Autofac作为DI容器的,使我决定使用它,以及其他的原因之一,是代表工厂功能(见here)服务定位器比依赖注入更容易使用?
也能正常工作的所有情况在那里我需要多次重新创建相同的元素,就像一些报告和相关屏幕一样。一些报告(即使是相同类型的报告)是同时执行的,但它们只是通过用户定义的参数进行更改,所以为了创建实例注入工厂是有意义的(我认为),传递免费参数并将其余部分留给应用。
问题伴随着每个报告由可变数量的子报告(任务)组成并且每个任务实现ITask接口。每份报告最多可以有50个不同的任务使用,每个任务都包含精确的业务操作。我有一个选择是注入委托工厂并在需要时创建它们。
这些任务必须由工厂和喜欢的东西是动态生成的:
var myTaskA = _taskFactoryConcreteTaskA();
var myTaskB = _taskFactoryConcreteTaskB();
var myTaskC = _taskFactoryConcreteTaskC();
...
var myTaskZZ = = _taskFactoryConcreteTaskZZ();
需要大量的手工布线(代表,构造,支持字段等等),而像
var myTaskA = _taskFactory.Create<ConcreteTaskA>();
var myTaskB = _taskFactory.Create<ConcreteTaskB>();
var myTaskC = _taskFactory.Create<ConcreteTaskC>();
...
var myTaskZZ = _taskFactory.Create<ConcreteTaskZZ>();
会特别是如果_taskFactory包装了容器,如this other post所示,但它也意味着我正在使用服务定位器来创建我的任务。
我有哪些其他选择可能适合解决此问题?
(注:有一个很好的机会,我完全偏离轨道,并且我要读了很多有关DI,在这种情况下,任何的贡献将更为重要)
Martin Fowler的写了这点:http://martinfowler.com/articles/injection.html#UsingAServiceLocator – mwilson
谢谢,这是什么让我再想想文章很多:HTTP: //blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx(并说服我购买这本书,但仍在等待它) – mhttk