为什么不将所有服务类都合并到工厂方法中(而不是注入接口)?

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

IEmployeeService
IDepartmentService
IOrderService
...

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

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.设置,并更多地整合依赖关系。

谢谢你的想法!