CODEWITHSUNDEEP
c#.netdesign-patternsrepository-pattern
Christian
Christian

Reputation: 1090

Advice for choice of Design Pattern

For as long as I can remember I have been using the classic 3 layer design pattern with Dependency Injection:

Presentation -> Service class -> Repository, and I always end up with the same problem: A few big Service classes that have way too much responsibility and code redundancy.

My mind have been poisoned by this design pattern after all these years, so I need a bit of advice to move on to something new. I have been doing some reading about other design patterns but there are so many choices and I fail to see the transition from my repository pattern to one of the many other patterns.

Basic example:

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...
}

The MachineService class will end up as a SuperService class, having the responsibility to create and update many different objects from my domain model. Because when something happens to an Machine object, then many other things need to happen. I usually have many more service classes but because of DI, I cant have a reference inbetween the service classes. That creates code redundancy. Any advice for a Repository pattern addict?

EDIT: I ended with Unit Of Work. See my solution here: https://stackoverflow.com/questions/41548169/rate-my-implementation-of-unif-of-work-with-repository-pattern-and-ef-core

Upvotes: 1

Views: 180

Answers (1)

Nazar Merza
Nazar Merza

Reputation: 3454

Having a super class has nothing to do with Service pattern or repository pattern or DI. It can happen anywhere with any pattern. It is a problem on its own that needs to be dealt with accordingly. It can be solved with applying proper class design guidelines, like SOLID. The most common cause of this problem is not adhering to S in SOLID. That is, if you design your class - service class is not exception - with a well-defined single purpose, you can avoid having these god classes.

In your case think of breaking down your classes into smaller classes. But, don't start from refactoring the code. Start at a higher level, for example some box and arrow (simple class diagram) to visualize entities you will have and the relationship among them. It is important not to delve into code while you are at this stage. Apply SOLID at this stage. Once this stage is thought through, then you can refactor existing code according to it. Without having this high-level view, things almost always get complicated.

Upvotes: 4

Related Questions