选择设计模式的建议

Question

从我记事起，我就一直在使用带有依赖注入的经典 3 层设计模式：

Presentation -> Service class -> Repository，我总是遇到同样的问题：一些大的 Service 类有太多的责任和代码冗余。

这么多年过去了，我的思想已经被这种设计模式毒害了，所以我需要一些建议来转向新的东西。我一直在阅读有关其他设计模式的一些资料，但有很多选择，我看不到从我的存储库模式到许多其他模式之一的转换。

基本示例：

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 类，负责从我的域模型创建和更新许多不同的对象。因为当机器对象发生某些事情时，需要发生许多其他事情。 我通常有更多的服务类，但由于 DI，我无法在服务类之间进行引用。这会产生代码冗余。 对 Repository 模式上瘾者有何建议？

编辑： 我以工作单元结束。在这里查看我的解决方案： 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。一旦考虑了这个阶段，您就可以根据它重构现有代码。如果没有这种高级视图，事情几乎总是会变得复杂。