c# - 为什么不将所有服务类都集中到一个工厂方法中(而不是注入(inject)接口(interface))？

Question

我们正在构建一个 ASP.NET 项目，并将我们所有的业务逻辑封装在服务类中。有些在域对象中，但通常那些是相当贫乏的(由于我们正在使用的 ORM，这不会改变)。为了更好地启用单元测试，我们为每个服务定义接口(interface)并利用 D.I.。这里有几个接口(interface):

IEmployeeService
IDepartmentService
IOrderService
...

这些服务中的所有方法基本上都是任务组，类不包含私有(private)成员变量(除了对依赖服务的引用)。在我们担心单元测试之前，我们只是将所有这些类声明为静态的，并让它们直接相互调用。现在，如果服务依赖于其他服务，我们将像这样设置类:

public EmployeeService : IEmployeeService
{
   private readonly IOrderService _orderSvc;
   private readonly IDepartmentService _deptSvc;
   private readonly IEmployeeRepository _empRep;

   public EmployeeService(IOrderService orderSvc
                        , IDepartmentService deptSvc
                        , IEmployeeRepository empRep)
   {
      _orderSvc = orderSvc;
      _deptSvc = deptSvc;
      _empRep = empRep;
   }
   //methods down here
}

这通常不是问题，但我想知道为什么不设置一个我们传递的工厂类呢？

即

public ServiceFactory
{
   virtual IEmployeeService GetEmployeeService();
   virtual IDepartmentService GetDepartmentService();
   virtual IOrderService GetOrderService();
}

然后而不是调用:

_orderSvc.CalcOrderTotal(orderId) 

我们打电话

_svcFactory.GetOrderService.CalcOrderTotal(orderid)

这种方法的缺点是什么？它仍然是可测试的，它仍然允许我们使用 D.I. (并通过工厂内外的 D.I. 处理外部依赖关系，如数据库上下文和电子邮件发件人)，它消除了很多 D.I.更多地设置和整合依赖项。

谢谢你的想法!

Answer 1

反对这一点的一个论点是它没有使您的依赖关系清晰。它表明您依赖于“服务工厂中的某些东西”而不是哪些服务。出于重构目的，准确了解什么取决于什么会很有帮助。

依赖注入(inject)应该让这种事情变得简单，如果你使用一个合适的框架 - 它应该只是创建正确的构造函数，定义什么实现哪个接口(interface)，并让它整理一切。