Migrating from traditional service layer to mediator pattern

[AsuraKev]

Hi people, in my project I currently have a traditional N-Tier layer architecture where it goes like this

Request -> Controller -> Service -> DbContext

The Service is doing the most heavy lifting and most of the business logic goes in there. A typical service can inject other services required to perform the operation, it also does a lot of querying and writing of other entities as well. e.g

async Task ApproveReleaseProcess(...params){
var a = serviceA.Get(blah blah);
var b = serviceB.WriteToDb();
var c = serviceC.GetById(b.Id);

}

I am struggling to see how I can transition from this to leverage mediateR pattern. Hopefully the answer is not Do all the querying on the controller layer because I would like the controller to stay clean and minimal.

thanks

[djjlewis]

So every case is going to be different and it's impossible to know all the context with the information provided. However, I can say that I was part of a team that did this, albeit a good few years ago now ~2016/2017 so my memory is somewhat faded.

We migrated gradually from a traditional Controller, Service, Repository pattern/architecture to almost the entire application being based around MediatR requests and request handlers.

As a general strategy, I would pick a public method on your service class and migrate this into a new Request RequestHandler e.g.
CustomerService.GetCustomer(int Id) -> GetCustomerRequest : IRequest , GetCustomerRequestHandler : IRequestHandler etc

You mention your services are dependent on additional services, in which case you have a couple of options:

1. Just inject the other services into the new RequestHandler and use them as before
2. Reimplement the shared service logic directly into the new RequestHandler

It's difficult to know which would be the better option without knowing your full context, but I'd tend to prefer option 2, unless you can identify shared domain logic that is required for multiple handlers (Jimmy has a good talk and blog series on exactly this topic https://www.youtube.com/watch?v=f64tZ90Dntg)

Over time, you will find you have extracted everything out of at least one service and all the logic is in request handlers, at which point you can delete the service.

As mentioned, treat "Shared" services with caution and favour keeping everything in the handler, unless you can really identitfy shared behavior. There is always a cost with coupling...

[AsuraKev]

@djjlewis thanks for the detail suggestion! I think I was thinking about mediateR in terms of CQRS where each IRequest can only be a simple query or a command and the example was using a really simple CRUD operation.

In my case where my service layer is doing much more then just a CRUD e.g

interface IService {
Task ProcessDocumentAsync(parameters: object)
Task DoSomethingComplicated(parameters:object)
}

class Service implements IService {
readonly IEmailService _emailService;
readonly IOtherService _otherService;
public constructor(IEmailService emailService, IOtherService otherService){
_emailService = emailService;
_otherService = otherService;
}

public Task ProcessDocumentAsync(parameters: object) {
... business logic here
}
public Task DoSomethingComplicated(parameters:object){
... business logic here

}
}

Would you say the mediateR version of this will be move ProcessDocumentAsync and DoSomethingComplicated methods into a class with handlers and inject email service and other service into it?

I am trying to think about the the benefit out of this approach because instead of injecting once on the Service class, now I need to inject N times for each of the methods ... :(

The question is tho, with CQRS you split the query and commands via something like MediateR. but most of the time the solution isnt going to be a straight forward read and write. I would imagine that a service would be sending out multiple query and commands during its business logic e.g

class Service implements IService {
readonly IEmailService _emailService;
readonly IOtherService _otherService;
readonly IMediator _mediator;
public constructor(IEmailService emailService, IOtherService otherService, IMediator mediator){
_emailService = emailService;
_otherService = otherService;
_mediator = mediator;
}

public async Task ProcessDocumentAsync(parameters: object) {
... business logic here
var value = _mediator.Send(....);
var value2 = _mediator.Send(....);
await _mediator.Send(...);

}
public Task DoSomethingComplicated(parameters:object){
... business logic here

}
}

[djjlewis]

I think I was thinking about mediateR in terms of CQRS where each IRequest can only be a simple query or a command and the example was using a really simple CRUD operation.

In my case where my service layer is doing much more then just a CRUD e.g

If cleaner CQS is what you are aiming for, then there is nothing that says you can't do 5 things in a command, or 5 things in a query.. you just want to separate your commands from your queries, and MediatR can help you enforce this a bit more.

Would you say the mediateR version of this will be move ProcessDocumentAsync and DoSomethingComplicated methods into a class with handlers and inject email service and other service into it?

It depends what these are doing and do they need to be called independently, but I am going to tenatively say "yes". Again, it's very difficult to say without the proper context. What I will say, is that multiple calls to mediator.Send() is definitely an anti-pattern. Generally, you will have one entry-point into your system raise one _mediator.Send (this could be from a controller, message queue subscriber, batch process timer job etc)... anything within the RequestHandler will then likely be using standard domain services (you can however use the _mediator.Publish() method as a way to send loosely coupled events (in process) to other parts of you system - a useful way to implement a modular monolith for instance).

A more mediator-esque way to rewrite your example would look something like as follows:

public class ProcessDocuments : IRequest {}
public class DoSomethingComplicated : IRequest {}

public class ProcessDocumentsHandler : IRequestHandler<ProcessDocuments>
{
    ProcessDocumentsHandler(IEmailService emailService, IOtherService otherService) { ... }
    
   Task Handle()
   {
     // ... do something
    _emailService.SendEmail();
    // ... do something else
   _otherService.DoSomething()

   }
}

public class DoSomethingComplicatedHandler : IRequestHandler<DoSomethingComplicated>
{
    DomSomethingComplicatedHandler(IEmailService emailService, IOtherService otherService) { ... }
    
   Task Handle()
   {
     // ... do something complicated
    _emailService.SendEmail();
    // ... do something else more complicated
   _otherService.DoSomething()

   }
}

Both handlers would only depend on the services they need. I will refer you again to that talk I linked to about refactoring to domain services, and just make sure the services you are injecting really are shared.. if there are things that are really only needed by one handler, then you're better off just moving that logic directly into the handler and using a simple transaction script approach..

If you have more of a long running workflow, you will need to evaluate if calling all these services in-process is appropriate, or whether something like durable functions, NServiceBus sagas etc would be better suited. If your current logic is all in-process and works as expected then there is no harm just calling the services directly from the request handlers..

It's also worth asking / reminding yourself what the benefit is you expect to get from using MediatR. I understand it was originally an answer to overloading controllers and service layers with multiple concerns and / or becoming god-classes. If you are not suffering from these problems, is it solving anything for you?

I still find MediatR of value as a logical separation point from the system entry points / UI to application logic, while the behavior pipelines are great for handling cross-cutting concerns, so there are still benefits to be had here.