Рекомендации по выбору Design Pattern

Question

Для тех пор, как я помню, я использую классический 3 слоя шаблон проектирования с Dependency Injection:

Презентация -> Сервис класса -> Repository, и я всегда в конечном итоге с Одна и та же проблема: несколько крупных классов обслуживания, которые имеют слишком большую ответственность и избыточность кода.

Мой разум был отравлен этим шаблоном дизайна после всех этих лет, поэтому мне нужно немного советов, чтобы перейти к чему-то новому. Я читал о других шаблонах дизайна, но есть так много вариантов, и я не вижу перехода от шаблона репозитория к одному из многих других шаблонов.

Простой пример:

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 я не могу иметь ссылку между классами обслуживания. Это создает избыточность кода. Любые советы для наркомана-репозитория?

EDIT: Я закончил работу с единицей. См. Мое решение здесь: https://stackoverflow.com/questions/41548169/rate-my-implementation-of-unif-of-work-with-repository-pattern-and-ef-core

Answer 1

Наличие суперкласса не имеет ничего общего с шаблоном сервиса или шаблоном хранилища или DI. Это может произойти где угодно с любым шаблоном. Это сама по себе проблема, с которой необходимо иметь дело соответственно. Его можно решить с применением правильных инструкций по дизайну, таких как SOLID. Наиболее распространенная причина этой проблемы - не придерживаться S в SOLID. То есть, если вы создаете класс класса - не исключение - с четко определенной единственной целью, вы можете избежать этих божественных классов.

В вашем случае подумайте о том, чтобы разбить свои классы на более мелкие классы. Но не начинайте с рефакторинга кода. Начните с более высокого уровня, например, с помощью некоторого поля и стрелки (простая диаграмма классов), чтобы визуализировать объекты, которые у вас есть, и взаимосвязь между ними. Важно не вникать в код, пока вы находитесь на этом этапе. На этом этапе примените SOLID. Как только этот этап продумано, вы можете реорганизовать существующий код в соответствии с ним. Без этого высокого уровня зрения почти всегда становится сложно.