Using MediatR in .NET? Maybe replace it with this 

@Tanglesites from where you change the ServiceLifetime to Scoped? No overlaod for method "AddMediator" taskes 1 arguments for "Mediator.Abstractions" Version="1.0.5"

@@abdullahghadawi6847 inside the AddMediator( options => ... ) extension method. Like Nick said, use the prerelease version.

The creators of the package can make this deviation between MediatR and Mediator a bit more obvious! Only stating that: "MediatR (...) does transient service registration by default, which leads to a lot of allocations. (...) IMediator and ServiceFactory services are registered as transient (not configurable)." is a bit quick! There is a big reason why Jimmy does it they way he does and having a scoped DbContext, or any scoped/transient dependency, makes it clear why Singleton is not the best options. Of course it is faster. Btw. the options is now in the final version (but yeah 9 monhts later 😅)

You saved my day ♥

That's my worries exactly. This doesn't seem production ready in an Enterprise environment

I like how I checked it before I published it too

That was fixed fast 😄

Id like this too. There's so many things out there but I never understand when I should be implementing them

Mediator is used to implement the CQRS pattern mostly. Business logic happens either in the command handlers or in the domain objects themselves (if using DDD). Of course you can be pragmatic about it and have some domain service that handles business logic too. Generally command handlers retrieve whatever is needed from repos and perform the necessary operations by calling upon methods on the objects or the repos and that's it.

You can step in, as long as you've configured the debugger to step in the code

Considering that MediatR itself is a pretty stale project because it’s feature complete, I wouldn’t worry about the commits, since there is feature parity already

I ask to MediatR mainteiner abouth accept a PR in a discussion in his repository and he said "No, sorry, that's not code I want to maintain."

I must add that personaly I dislike the service locator pattern

I never said that the problem is reflection. It is the function resolvers that generate the handlers for the requests that cause the problem (though memory pressure and gc pauses)

@@nickchapsas thank you for the good video and the reply, I am sorry if I misanderstood. But what I understand is that source generators cleans the reflections and the dictionary lookup, the first is only startup and the second will be very low impact inside an api service. Even with code generation transient and scoped handlers must be allocated and garbage collected. Using factory di methods its possible to ease GC pressure and still have most mediatr features. I asume pooling can be used with this Source generated package to have even better performance. Thanks for the great videos and streams

did you find a solution for this issue? I'm facing the same issue

@@mohamedelbasmy5160 not, I gave up and used the old mediator, I haven't tried recently

No it's not and no the compiler won't decide to use a dictionary to the IL if you use a switch. You are making a lot of false assumptions there. I've covered all this in a video on improving the performance of enums in C#

@@nickchapsas I have already watched that video back when you released it, since I do enjoy your videos 😁, but that video doesn't talk about how the compiler compiles switch statements, I would link to (admittedly old) sources which show the compiler will compile the switch to different IL depending on case numbers etc. But RU-vid doesn't like that, it may be old and not be true anymore since the dotnet compiler is always getting better.

@@MiningForPies application startup time can be different since we give more work to JIT. But it''s important in a very few cases, generally ahead of time > reflelction

Runtime operations have way longer times than compile-time ones, even if you include the JIT

The Java world is obsessed with differeny patterns. Mediator is mainly a .NET ecosystem thing

Mediator has nothing to do with event sourcing just fyi

@@edvardpitka3902 yeah it's used for CQRS. What I meant was in Java when learning about CQRS they always uses event sourcing. An ex, is with Axon server. But was jus wondering if there is the mediator alternative for Java without having to use their controller, service, repository patterns. I don't even know why they try to have "thin" controller in Java when their services class is huge.

That’s because of the feature parity with current MediatR. MediatR itself is pretty in active because it’s effectively feature complete.

@@nickchapsas that's good to know, thanks!

I’ve been using this library for a while. You can see I’m the last issue on it. It’s a good library, the creator is very responsive, and if you have have concerns, your welcome to make pull requests also

Highly unlikely especially considering that this has been possible for a long time and the package existed for a long time too. I haven't seen Jimmy try to merge source generated Automapper implementations either which would arguably benefit way more from something like this

Or the ability to use Mediator with the new NativeAOT capabilities which is also pretty sweet.

@@nickchapsas I'm not sure OP was saying the source generated MediatR solved this problem. It certainly makes it *better* since you can step into without having to locate the actual source file and get a good idea of what's going on. But there's still no direct line you can draw between the point the Send function is called and the source code that runs when you call it, and the amount of work is elevated from "right click --> view implementation" to "set breakpoint --> run --> step into --> note class name --> stop debugging --> solution search name --> identify and open file." This is a HUGE process problem being introduced into the application, and most people honestly get very little tangible benefit, so it's a net loss for most. The way people get around this, that I've seen, is putting the requests and the handlers in the same source file so you can view implementation on the request and do just fine. And that can work if you keep stuff simple, but I've seen people get inheritance involved and it was a nightmare lol

@@andrewshirley9240 just like there is a way to step into the generated code, there is a way to write your generated code to file system on build. That would give you ability to navigate to implementation.

@@andrewshirley9240 I'm not sure how other people use mediator. Where I work, all handlers have a command object of type IRequest, which will be a one-to-one with the handler, and the handler is IRequestHandler. When calling Send we create a new command, pass in any args (or an empty object if there are no args). So if we go to the controller we can CTRL + click on the command to go to command file. To simplify matters further, we combine the command and handler in the same file, since the command is useless without the handler. That gives us quick access to the handler from the controller. No breakpoints required to figure out what is getting executed.

@@andrewshirley9240 Exactly one of the reasons we removed it from our project after playing with it little bit.

No it doesn't Old uses old MediatR and new uses the new source gen

Here you go: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-mEhkelf0K6g.html

@@nickchapsas I mentioned that I know it, and It describes to use on hot-path same description as the inventor of ValueTask did, but I want to know more about it. Ex: other cases like EFCore that uses it also when is not hot-path there. Thank you.

Why wouldn't you?

@@nickchapsas I know the nice thing with MediatR is its "pretty much" automatic integration with FluentValidation if you're using the proper dependency. Here I feel like I have to change to pipelines so it's not really plug & play anymore 😅

@@bugsoli You'd have to write the pre-pipeline which is literally 10 lines of code

@@bugsoli you still need to implement a BehaviorPipeline for fluentvalidations with MediatR

@@kabal911 correct after going back to my code, I see that the MediatR.Extensions.FluentValidation does just that... weirdly though when I code it myself using Mediator, it does not validate so I'm missing something somewhere 🙂

I think that using MediatR's API is a very smart choice by the creator. You basically get a drop in replacement which would be the biggest migration complaint.

@@nickchapsas Exactly, it is! Is by far the smartest idea I ever see. But, I don't know... I just feel bad about use it, is like said "I'm using your evil twin now" to MediatR Leaving aside the moral issue, I'll see it. I have a framework that uses MediatR approach, and this can be a pretty usefull upgrade for performance and memory use

There aren't any downsides in this particular scenario. Jimmy makes packages for him and he happens to open source them so I assume it's because he himself, doesn't need to.

It’s worth to have a discussion up there. I’d love to see these merged and just an option in MediatR

Isn't the code base larger with the source code generation? (Not that really is a relevant disadvantage)

@@jasdefer which? MediatR or the application? The source generator would be at compile time and not committed

@@DanielAWhite27 thanks, I thought that the application would be slightly larger, because of the code (switch statements) generated.

Not any real drawbacks. The only thing I can think of is that you assemble all be bigger due to source generation but it’s not really a “drawback”

@@nickchapsas Good to hear. At some point maybe you take a look at Actor models with message queues and maybe contrast with the mediator pattern, especially in CQRS context.

What do you mean by “maintainable”?

I have touched on this on many videos but I might make one dedicated to this topic so I can link to it.

"Good" reflection is only done once at start-up and all results are cached for fast lookup during the life of the application. "Bad" reflection is done every time something is needed, slowing down the application.

Is he? Has he talked about this publicly?

As you can see in the video MediatR has a high memory footprint per request. When you're working with 100s or 1000s of requests per second, you build up memory pressure that needs to be garbage collected, leading to micro pauses. This can have a big effect in performance and I've shown a video in the past on how the MediatR version is slower than the non-MediatR version in real world scenariors.

@@nickchapsas yep, I saw that video. But I'm just wondering whether we really need to use MediatR all over the place because it's handy and popular, or we could use it for the real problem solving?

@@nanvlad this is what I was wondering lately, usually MediatR is used just to separate controller from its action handling code, you could easily add "businessProvider" class for each action in controller and into the constructor and call its handling method in their action, you would get same thing like with MediatR if you don't use anything more from MediatR like automatic command/query validation or other middleware stuff. Using MediatR in every project makes you "cool" even if the project rly doesn't need it :)

@@lordicemaniac for us, using mediator has nothing to do with “being cool” and everything to do with having simple, consistent patterns that are easy to understand. Sure, you can implement your own way of doing things, but if it’s not based on generics, then you probably end up with lots of dependencies injected into your controller, or you have some sort of “wrapper” dependency that has the other dependencies injected into it. So to do it nicely, your probably end up implementing mediator, just a worse version. Funny how no one has a problem using controllers/actions, which IS the mediator pattern.

I don't understand the obsession with cutting down your 3rd party libs. I've heard the reasons but I find them silly or maybe more valid for the .NET Framework times. I would be very surprised if Jimmy changes MediatR to be source generated, especially considering that he hasn't done that with Automapper which is a way more obvious and fitting migration.

When is a random lib not a random lib anymore?

​@@nickchapsas I don't understand the obsession with 3rd party as well. The worst-case scenario is something being completely abandoned but the alternative is to either implement it yourself or skip it altogether. What is the point of not using libraries if they are available? I've heard the reasoning for it, I just never had any issues in my 10 years working as developer. The only problems I had were with library encapsulation, which to me usually means "adding bugs that wouldn't exist otherwise" and "adding complexity and maintainability issues that you wouldn't have."

@@nickchapsas You of all people should understand. 3rd party is unauthorized code, you don't want that in your core. You don't wanna stumble upon a bug you don't have control over, because it resides inside a 3rd party lib. It's not an obsession, it's just logical common sense and widespread knowledge among experienced developers.

@@codex4048 You decide for yourself, it's your responsibility your code works right. MediatR has 86M downloads and 60+ contributors. It's well known in the programming community. Well tested. I think MediatR qualifies as "not random", but dude, you decide what is random for you.

I encountered the same problem. I think the reason for the problem is that the objects (mediator) and packages (mediator dll's) are not in the same project.

Thank you I will try it.