[Best Practice?] API (MediatR) --> calling class library (Mediatr)?

[jeffward01]

Hello!

I am wondering best practices and if this is 'bad' class library design' or not. I understand that nested director handlers are bad from this issue here: #434

Scenario

I build many class library nuget packages. I like to put MediatR in the nuget packages so it is cleaner. For example, a nuget package class library which reads .csproj files. (This is not my library, but it is similar to this library: ByteDev.DotNet.) Imagine that this library uses MediatR internally to execute commands and return results.

Then separately, I have an API application. The API application also uses MediatR. The API application will have ByteDev.DotNet installed as a package.

The API application will call a API MediatR Handler --> API Service --> then the API service will call the class Library handler --> Class Library MediatR handler.

Question

• Is this bad practice?
• Should I refrain from using MedatR within class libraries (nuget packages)

Thanks all!!

[jbogard]

Ah good question - I try to have MediatR as the top-level request/response in a system because things like behaviors get quite tricky. You can't turn them easily off/on for specific requests. From the diagram above it looks like that whole chain is in one process? If that's the case I might create my own little request/response library, that doesn't have all the features of MediatR, for all the "internal" request/responses.

[jeffward01]

Thanks for the awesome answer! I see you active on Reddit too occasionally, its very cool to read your posts! I really appreciate your advice on this, I try to keep best practices as much as possible, it reduces the pain later as the code is used in other implementations and scales!

I wrote a somewhat long winded comment, sorry. I wanted to provide as much context as possible. I have 2 summary questions posted at the bottom to try and save your eyes.

Thanks again!!

My Reply

I try to have MediatR as the top-level request/response in a system because things like behaviors get quite tricky.

Perfect, this makes complete sense. I think the take-away here is:

have MediatR as the top-level request/response

This keeps it clean, and free of issues like you mentioned. I was afraid that the overlapping MediatR calls would 'step' on each other, or return before the child MediatR had produced a result, some strange activities like that. by Keeping MediatR to top-level you avoid all this.

From the diagram above it looks like that whole chain is in one process?

Yea, in this case it is one process, an example process is below. I tried to make the process as clear as possible, sorry if its confusing:

• [API Assembly] API Controller executes IMediator GetAllCsProjectPackagesHandler (for example)
• [API Assembly] Then within GetAllCsProjectPackagesHandler, this will consume a service which also is in the API assembly, ICsProjectService for example.
• [API Assembly] Then the ICsProjectService will then consume 1-4 library API calls from the installed nuget library assembly such as (this is where the nested IMediatR calls occur):

• [Nuget Library assembly] CanCompile()
• [Nuget Library assembly] HasPackages()
• [Nuget Library assembly] GetPackages()
• [Nuget Library assembly] HasOutdatedPackages()

---

If that's the case I might create my own little request/response library, that doesn't have all the features of MediatR, for all the "internal" request/responses.

Usually for results I use something like FluentResults, sometimes I modify it, but it seems to be pretty flexible for my usecases.

I think I you might be referring to implementing a CommandPattern similar to something one of these:

• Orchestration
• CommandPipeline

Is this what you mean?

---

I really appreciate the advice!! I will do this and make these changes! Thank you!

Below, I elaborate on a use-case where I like to use MediatR in my libraries so I do not need to inject 10+ services in some cases. It's a bit long, but you might find it interesting.

Class Library usecase for MediatR (skip this if you want)

For example, I have this Cross-Platform Filesystem library I am building which is a modified version of: Singulink.IO.FileSystem - and Singularlink.Filesystem is a modified version of AlphaFS which is basically a FileSystem library for Windows, it adds extra functionality into System.IO to easily deal with Permissions, Attributes, add Progress<> counters, things of this nature.

In my library, I have some methods which parse paths into AbsoluteDirectoryPath or AbsoluteFilePath objects, by something that looks like this:

The IAbsoluteFilePath will have many services injected such as:

• ICopyFileService
• IMoveFileService
• IBackupFileService
• IFileAttrebuteReaderService
• IFileHardlinkService
• etc...

The goal would be able to perform something like this:

var myAbsoluteFile = _pathParserService.Parse(somepath);

// It would be nice to have all these actions encapuslated within the IAbsoluteFilePath. 
// This makes the API of IAbsoluteFilePath cleaner and all in a single 'place'.
myAbsoluteFile.Copy(someDestinationPath, out Progress progressReporter);
myAbsoluteFile.CreateHardLink(someDestaintion, someEnum);

Instead of injecting all the services, I find it really clean to use IMediatR such as below:

public class SomeClass
{
    private readonly IPathParserService _pathParserService;

    public SomeClass(IPathParserService pathParserService)
    {
        _pathParserServicve = pathParserService;
    }

    public IAbsoluteFilePath Parse(string path)
    {
        // Some validations...
        return _pathParserService.Parse(path);
    }
}

The path parser behaves something like this:

public class PathParserService
{
    private readonly IMediator _mediator;

    public PathParserService(IMediator mediator)
    {
        _mediator = mediator;
    }

    public IAbsoluteFilePath Parse(string path)
    {
        // Some OS Platform path validations and such...
        return new AbsoluteFilePath(path, _mediator);
    }
}

// This is where IMediator saves your brain-power and code organization:
// If I did not use IMediator, instead of injecting only _mediator, would have to inject all of these services:
* `ICopyFileService`
* `IMoveFileService`
* `IBackupFileService`
* `IFileAttrebuteReaderService`
* `IFileHardlinkService`
* etc...

The code above is pseudo-code for a FileSytem library, I agree with you that using IMediatR in classes that are not 'top-level' is the best way to go. But also in situations like this, its quite nice to use IMediatR so I only need to inject (1) service instead of (10+). It's more of developer laziness I imagine using IMediatR instead of manually injecting.

Final Questions

1. In cases like above, where a library would need to inject 8-10 services in an object in order to avoid using the 'ServiceLocatorPattern, would you still recommend keeping IMediatR as 'top-level' calls only?
   -- ie: never put IMediatR in a class library?

2. When you mention "I might create my own little request/response library" do you mean a 'CommandPattern' similar to one of these libraries:

• Orchestration
• CommandPipeline

Big thanks again! I hope that this thread is helpful to others as well who would like to use IMediatR within class libraries.