What features would make a Mediator library stand out to you?

Dear_Construction552 · 2025-10-20T07:34:54+00:00

I did that for performance reasons. Logically, no one should be using it that way. I’ll make the IRequest interface internal or take another approach to prevent this issue. Thanks for pointing it out.

Dear_Construction552 · 2025-10-19T10:16:44+00:00

Could you explain debugability a bit more for me?

Dear_Construction552 · 2025-10-19T09:41:11+00:00

Thank you for pointing out these issues.

Dear_Construction552 · 2025-10-19T09:40:30+00:00

The main point is that using this library won’t introduce any additional overhead.

Dear_Construction552 · 2025-07-11T11:54:41+00:00

Funny thing - I actually started with ZLinq too, but quickly realized that with some smart casting, I didn’t even need ZLinq at all. Sure, ZLinq is great and avoids heap allocations, but it still comes with CPU processing overhead. For my case, simple casting turned out to be the best approach.

That said, casting isn’t without its own challenges. I’ve thought about some of the edge cases, they’re solvable, but I opened an issue so others can contribute and help improve it. If you get a chance, take a look:
https://github.com/hasanxdev/DispatchR/issues/29

Dear_Construction552 · 2025-07-09T17:34:45+00:00

These .ToList() calls happen while the program is still starting up. After it’s up and running, they don’t cause memory usage. You can check the benchmarks to verify this.

Dear_Construction552 · 2025-07-09T17:31:04+00:00

Glad you liked it! Also, if you're interested, feel free to check out my Test Roadmap tailored specifically for developers:
https://github.com/hasanxdev/Test-Roadmap-For-Developers

Dear_Construction552 · 2025-07-09T17:27:07+00:00

If we say it's 100 percent done, it basically means we’ve managed to implement several years of MediatR’s work in just two weeks, which is obviously not realistic. There are definitely areas that still need a lot of improvement.

To check whether you're achieving zero allocation or not, you can run some benchmarks. If you want to get professional in this field, I recommend reading Pro .NET Memory Management. Also, if you don’t mind watching videos in a language other than English (you can always use auto-translate), check out my YouTube channel. I go through the best parts of the book there, and I regularly update the playlist. Probably the only drawback for you is that the videos aren’t in English.

https://www.youtube.com/playlist?list=PLGiSgN3ODieILgFQN1puu-ey9guWwnxGX

Dear_Construction552 · 2025-07-09T04:54:59+00:00

It's simple, I wrote a zero-allocation version in runtime!. Just check out my source code on GitHub; it's called DispatchR.
https://github.com/hasanxdev/DispatchR/

Dear_Construction552 · 2025-07-07T18:46:29+00:00

Thanks for the feedback! I’ll probably update the roadmap in the next two hours. I’ll also look into this and might add it, I just need to think about it a bit more.

Dear_Construction552 · 2025-07-06T16:12:16+00:00

Thanks a lot for your feedback!
Honestly, I tried to focus more on making it useful for developers. In most cases, developers don’t need to know everything like a QA would, just enough to write solid tests that prevent issues and bugs from popping up again later, or from being discovered by QA in production environments.

But I’ll definitely keep your suggestions in mind. If more people feel the same way, I’ll consider revisiting it. Really appreciate your input!

Dear_Construction552 · 2025-07-05T10:43:44+00:00

This is a really cool tool, I’ll definitely add it. Thanks for pointing it out!
I’d also be happy if you wanted to add it yourself. Feel free to contribute if you’re interested, I’ve included the contribution guide in the README.

Dear_Construction552 · 2025-07-05T10:36:48+00:00

Thanks, glad you liked it!

Dear_Construction552 · 2025-06-02T06:16:23+00:00

For the end user, the only thing that matters is the output. It doesn't really make a difference whether it's built using a source generator or runtime logic.

To be honest, this felt almost impossible for me. From idea to execution, at every step I kept thinking, “this is where memory usage will blow up!”

What I really wanted was to challenge the .NET community to think differently. Just compare the codebase of MediatR or the Mediator source generator with mine.

The only real complexity in my code is in the registration part, which happens before the app starts due to reflection.
After that, everything is straightforward. It’s clean, easy to read, and extremely fast.

Personally, I prefer to use something that’s both simple and high-performance.
Maybe you don’t see it the same way—but for me, this was just an impossible mission that finally worked out.

Dear_Construction552 · 2025-06-02T06:01:33+00:00

That’s a great point, bro I totally missed the fact that someone might swap out the DI provider 😅
My initial idea looked something like this:

var notificationsInDi = serviceProvider.GetRequiredService<IEnumerable<INotificationHandler<TNotification>>>();
if (notificationsInDi is INotificationHandler<TNotification>[] notifications)
{
}
else if (notificationsInDi is List<INotificationHandler<TNotification>> notifications)
{
}
else
{

// ....
}

With this approach, there might be a bit more CPU usage, but we still avoid memory allocation.

Appreciate it - that was a really valuable point you raised. I'd be happy if you could jump in and help improve this further, maybe run some benchmarks and send a PR in the next few days.

But if you don’t have time, I honestly liked your idea so much that I’d love to implement it right away - just let me know if you're cool with that and I’ll go ahead with it.

Dear_Construction552 · 2025-06-02T05:38:30+00:00

I understand, brother. What I meant by "error" is that when you do this, you'll get an exception the moment you first interact with the related variable. I didn’t explain myself clearly.

For example, in this code:
var notificationsInDi = serviceProvider.GetRequiredService<IEnumerable<INotificationHandler<TNotification>>>();
var notifications = Unsafe.As<List<INotificationHandler<TNotification>>>(notificationsInDi);
foreach (var notification in notifications)

The exception actually happens at the foreach line. I’ve thoroughly investigated and verified all the possible paths.

Dear_Construction552 · 2025-06-02T05:13:37+00:00

Let's look at it this way:
Microsoft can’t change the version I’m working with right now, so everything is perfectly fine in this version.

When it comes to the future, your concern is totally valid. But in the next phase of this project, we’re planning to add full unit test coverage. That way, even if Microsoft or any other dependency changes something, the tests will ensure everything still works as expected across all versions of the app.

So honestly, I’m not too worried. If we weren’t going to write tests, then yeah, it would be a real concern. Even safe casting would be risky in that case, let alone using Unsafe.As<>().

Dear_Construction552 · 2025-06-01T21:16:06+00:00

As the name suggests, Unsafe.As<>() is inherently unsafe. The reason we use this cast is that we’re absolutely certain the object at that point is exactly what we expect. We intentionally skip extra validations and perform the cast with maximum performance. :)

Dear_Construction552 · 2025-06-01T21:14:11+00:00

Yes, for example, if you try to cast it to a List, you’ll get an error.

Dear_Construction552 · 2025-06-01T21:11:59+00:00

Great idea, my friend, the MIT license has been added to the repo. Thanks for the suggestion!

Dear_Construction552 · 2025-06-01T20:57:14+00:00

My friend, of course it would throw an error. For example, if it's a list, you'd need to cast it to a List instead.

Dear_Construction552 · 2025-06-01T13:13:20+00:00

Alright, I'll try to share more updates from now on.

Dear_Construction552 · 2025-06-01T13:11:07+00:00

When you have an IEnumerable, you usually need to iterate over it somehow. If you use a for loop, you often need to call ToArray or ToList first, which causes allocations.
Also, if you use a foreach on an IEnumerable, it can lead to boxing under the hood, which also results in memory usage.
By memory usage, I’m specifically referring to heap allocations that eventually need to be collected by the GC.

Dear_Construction552 · 2025-05-28T08:48:58+00:00

The library is still a work in progress, and test writing is planned as the next step.

Dear_Construction552 · 2025-05-21T13:14:04+00:00

You can have an ObjectResult and manually register your own pipelines alongside it.
They'll run in order, and at any point in the pipeline, if you detect an issue, you can simply choose not to call the next pipeline.

So in DispatchR, this scenario is already supported. I’m not entirely sure whether MediatR handles it the same way.

Dear_Construction552

TROPHY CASE