Question

只要我记得我一直在使用经典的3层设计模式和依赖注入：

演示文稿 - ＆gt;服务类 - ＆gt;存储库，我总是遇到同样的问题：一些大的服务类负有过多的责任和代码冗余。

这些年来，我的思维已被这种设计模式所毒害，所以我需要一些建议来继续学习新的东西。我一直在阅读有关其他设计模式的一些内容，但是有很多选择，我没有看到从我的存储库模式转换到许多其他模式之一。

基本示例：

public void CreateMachine(Machine machine)
{
    this.repository.Insert(machine);
}

public void StartMachine(Guid machineid)
{
    Machine machine = repository.GetMachine(machineId);
    machine.Started = true;
    repository.UpdateMachine(machine);

    MachineEvent mEvent = new MachineEvent(machineId);
    mEvent.MachineId = machineId;
    mEvent.EventType = MachineEventEnum.MachineStarted;
    this.eventRepository.Insert(mEvent);

    If (machine.IsBigMachine == true)
    {
         // Do something more
    }        

    // many more objects to create or update...
}

MachineService类最终将作为SuperService类，负责从我的域模型创建和更新许多不同的对象。因为当Machine对象发生某些事情时，需要发生许多其他事情。我通常有更多的服务类，但由于DI，我不能在服务类之间引用。这会产生代码冗余。对存储库模式上瘾的任何建议？

修改我以工作单位结束了。在这里看我的解决方案 https://stackoverflow.com/questions/41548169/rate-my-implementation-of-unif-of-work-with-repository-pattern-and-ef-core

Answer 1

拥有超类与服务模式或存储库模式或DI无关。它可以在任何地方发生任何模式。这是一个需要相应处理的问题。它可以通过应用适当的类设计指南来解决，例如SOLID。导致此问题的最常见原因是不遵守SOLID中的S.也就是说，如果你设计你的类 - 服务类也不例外 - 具有明确定义的单一目的，你可以避免拥有这些神类。

在您的情况下，请考虑将您的课程分解为较小的课程。但是，不要从重构代码开始。从更高的层次开始，例如一些框和箭头（简单的类图），以可视化您将拥有的实体以及它们之间的关系。在此阶段，不要深入研究代码是很重要的。在此阶段应用SOLID。一旦考虑了这个阶段，您就可以根据它重构现有代码。没有这种高级别的观点，事情几乎总是变得复杂。

选择设计模式的建议

1 个答案: