Don't let MediatR hold you back, try this...

[@RawCoding]

Why I don't use MediatR kzbin.info/www/bejne/nXq5paV4qbdgj9k

[@DanWalshTV]

I definitely would've preferred the "ceremony" interface over using a forced naming convention that is more error-prone, but maybe that's just me. With that said, the project looks cool (along with its sibling project, Marten) but I don't really see anything that would compel me to use it over the already production-ready and feature-rich MassTransit as of today. I'll be keeping an eye on its progress though, will be interesting to see how it looks once they reach v1.0. I gave them a star on GH last year.

[@ArmanHaeri]

I also completely agree with what you've stated

[@shadmansudipto7287]

I also completely agree with what you've stated

[@stefano_schmidt]

I also completely agree with what you've stated

[@IvMisticos]

I also completely agree with what you've stated

[@lucasxavier948]

I also completely agree with what you've stated

[@adrian_franczak]

I like this ceremony with interfaces so I don't have typos in my code xD

[@DanWalshTV]

Agreed. Aside from the fact I don't believe a third-party library should enforce a naming convention on application code, it's simply more error-prone than using an interface.

[@majormartintibor]

@@DanWalshTV you can very easily write Architecture tests that enforce the naming convention and eliminates the error possibility. Also the naming convention is pretty much the exact same as most of us name our shit anyway.

[@ernest1520]

I'm surprised to hear that mediator has a bad opinion these days. Things going full circle I see. If someone is complaining about the explosion of numerous classes when using mediator, they should first look in the mirror because that's where likely the root cause of their problems is. When things are properly architected, then mediator with its handler classes only empowers things and promotes the single responsibility principle.

[@eradubbo]

When things are properly architected there is no need to be dependent on Mediatr, Automapper or any other third party libraries not necessary

[@IvanRandomDude]

Poor Jimmy Bogard. Few years ago everyone was hyping his libraries. Nowadays, everybody is trashing them.

[@ernest1520]

People being people

[@PaulPendor]

Not everyone. Just the people who jump on to the next dogmatic hype, rather than really thinking about their domain, their problems and their specific situation. That’s why everyone goes microservices first and introduces lots of complexity, rather than figure out what actually needs to be microserviced.

[@tumelomotsikelane]

I have been following wolverine for some time. I can't wait for it to be production ready

[@kavunr]

Very cool stuff, I like that it can be used as an in memory mediator ala-MediatR, but extended per message to use a queue. I recently starting using Mediator (code generated version of MediatR) but Wolverine makes a lot of sense if I need to distribute commands/notifications in the future.

[@19balazs86]

Hi Anton, thanks for the video! Wolverine and Marten are getting more and more attention. I can not wait for more tutorials to showcase all the goodies they offer.

[@rustamhajiyev]

I don't know about you people, but I don't like to use conventions unless they are your own (there is a place in your project where someone can check which conventions you have decided to use). Anyway, thanks for the content 👍

[@ИванИванов-я5э9к]

Cool thing! You show a lot of useful stuff! Thanks, I really appreciate it. U help us to become better!

[@mottahh4162]

I really hate the libraries that depends only on naming I believe using interfaces is much more cleaner and less error prone

[@PaulPendor]

Yes, that was my first thought. I’ve seen so many instances where naming conventions have lead to bugs. Interfaces give you compile time failure feedback rather than runtime feedback.

[@marna_li]

Awesome to see so many alternatives to MediatR! I do use MediatR internally, and MassTransit for integration events. It's by habit from how I learned it. But I might as well use MassTransit in my entire application since it supports Mediator and Outbox pattern and so on. I do think that MediatR gives a cleaner interface. But I'm also very tired of having all these classes for Endpoint and Handlers.

[@ivanvincent7534]

Have you used Brighter?

[@RawCoding]

No

[@cocoscacao6102]

I wouldn't replace MediatR with this, but damn... This is a vary fine library (even though it's in early stage). Sharing is caring :)

[@adrian_franczak]

This vs masstransit video!

[@andrewiecisa2907]

I use Masstransit and is as simple to setup as your demo

[@jeremyhb1393]

Good job!! 🖐 thanks for the explanation, would you please make a video talking about the adv and dis of using application-level triggers in efcore there is a library named EntityFrameworkCore.Triggered use it as an example .

[@fieryscorpion]

It’s pretty neat! Dayummmm.

[@OeHomestead]

Next week: "Still using Wolverine? Stop it! Make your own solution."

[@RawCoding]

The jig is up

[@rentefald]

Exactly.. stop using all these frameworks, just build it your self.

[@PaulPendor]

It’s like it’s some sort of click bait headline right 😂

[@frankhaugen]

I have started to reduce my use of "patterns in a nuget"

[@xRealHackerx]

Wolverine is good only for hello world apps. SQS docs are almost missing and nothing is changing for months.

[@coolmn786]

Me hides in the corner coz I like mediator.. oops

[@frankhaugen]

You are allowed to have your own preferences

[@DanWalshTV]

There's nothing inherently wrong with it. This is more of an in-process vs disturbed discussion (it'd be no different comparing Mediatr and MassTransit). If you only require in-process for your use cases, continue happily using Mediatr regardless of what others say.

[@ivanvincent7534]

@@DanWalshTVexactly.. not sure the comparison in this video is fair.

[@NickSteffen]

Yea, I definitely think it’s good for something’s, I think for the typical use case people demonstrate in an api that will only ever call the same handler it’s a bit over the top though. Your really only getting the standardized pipeline behaviors at that point and Mediatr itself is just a glorified function call. I’ve used it in a couple projects that have to execute lists of arbitrary different commands in sequence and it’s really good for that. Replicating the functionality it provides in that case with dictionaries and some other stuff would be painful.

[@zfold4702]

Good you got a haircut but what happened to your eyes?

[@lettuceturnipthebeets790]

finally, someone said it! mediatr makes the developing process so much longer than necessary, it's awful sometimes >.

[@ddrsdiego]

maybe it's because you don't know design patterns, think like that.

[@ernest1520]

If adding a request class (or even better- a record) and a corresponding handler makes the process "much longer" then I don't think that the problem is with the tool...

[@lettuceturnipthebeets790]

​@@ernest1520 well yeah, it's exactly so - creating a separate record and handler instead of a simple service method call easily tripples the time of the initial setup (not talking implementation logic of the handler/method, just the setup)

[@bogdanb904]

@@lettuceturnipthebeets790 So you're telling me that making a service class, with respect to SRP so you don't have 50 random methods in there, exposing a method(the handler), that accepts some input (the request record) takes longer?

[@lettuceturnipthebeets790]

​@@bogdanb904 ...of course? look at it this way, imagine you have a service, but for every method you must create a separate record. it's already longer by itself. now if you want to use MediatR for the same purpose, not only you have to create a unique record for every handler call, but also the records repeat a lot (talk the endless single-id-property query records), while also having to implement a sh*tload of interfaces

[@botyironcastle]

err prone

[@PCM-Data8]

Have you tried `Paramore.Brighter`, and `Paramore.Darker`?