我正在处理的应用程序依赖于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的内容,在这种情况下,任何贡献都会更为重要)
答案 0 :(得分:6)
由于问题中指出的工厂没有采取任何论据,使用 Leaky Abstraction 的工厂气味。正如Nicholas Blumhardt在答案中指出的那样,更好的办法可能就是将每项任务都注入消费者手中。
在这种情况下,由于所有任务都实现了相同的界面,而不是注入多达50个不同的ITask
个实例,您可以编写它们:
public class MyConsumer
{
private readonly IEnumerable<ITask> tasks;
public MyConsumer(IEnumerable<ITask> tasks)
{
this.tasks = tasks;
}
public void DoSomething()
{
foreach (var t in this.tasks)
{
// Do something with each t
}
}
}
或者,您可以将ITasks
的序列组合成Composite,这实际上是我首选的解决方案:
public CompositeTask : ITask
{
private readonly IEnumerable<ITask> tasks;
public CompositeTask(IEnumerable<ITask> tasks)
{
this.tasks = tasks;
}
// Implement ITask by iterating over this.tasks
}
这将简化消费者,并将有多个任务执行的事实转化为实现细节:
public class MyConsumer
{
private readonly ITask task;
public MyConsumer(ITask task)
{
this.task = task;
}
public void DoSomething()
{
// Do something with this.task
}
}
答案 1 :(得分:3)
值得研究的一种方法是将问题分解为使用一组相关任务的“工作单位”:
public class WorkItem1 : ISomeWork
{
public WorkItem1(Task1 t1, Task2 t2...) { }
public void DoSomething() { ... }
}
然后,您对工厂的使用会降至someWorkFactory().DoSomething()
,可能会出现几种不同的'某事'。
在工厂或其他任何事物上具有大量依赖关系的类通常指向等待被发现的更小,更集中的类来分解工作。
希望这有帮助。