search

jbogard / MediatR

Simple, unambitious mediator implementation in .NET
Apache License 2.0
11.21k stars 1.18k forks source link

Behaviors specified as attributes of Request #694

Closed vaclavholusa closed 2 years ago

vaclavholusa commented 2 years ago

Hi folks! I’ve came across a dozen projects using MediatR for sending commands/queries from controllers to application layer. Not sure why using behaviors for validating or loading extra data is considered bad practice but literally every one of those projects was using it exactly like that. And it was always a mess in terms of behaviors registration. Usually ending up with an extension method for IServiceCollection called RegisterBehaviors having sometimes hundreds of lines with behavior registrations. What I definitely hate here is guessing what behavior is used in what pipeline. I always had to go via “Find all references” and sesrching for the registered behaviors.

This gave me an idea of creating a library that will solve my biggest issue. I called it AttributedBehaviors and you can check out the docs on github MediatR.Extensions.AttributedBehaviors

Even though some might say this is not what behaviors were intended to be, it makes life really really easier and potentially saves a lot of ripped hair. I already applied it to a bunch of projects I have an access to and always got a very positive reactions.

Hope you’ll find it useful as well.

jbogard commented 2 years ago

Hundreds??? Holy moly

vaclavholusa commented 2 years ago

Well, this speaks for itself - around 120 behavior registrations. image

So you can imagine that my extension made these developers really really happy.

ronnieholm commented 2 years ago

What does some of these do? Their names read mostly like misguided use of pipeline behaviors. Why not put this logic into the actual handlers? If not the immediate handler then handlers which react to published events.

MichaelHochriegl commented 2 years ago

Sorry, but why is Validation in a pipeline a bad idea? I used this up until now to do my validation and if it fails, return a bad result (so no Exception). Thought this was a pretty nice use of pipelines alongside logging.

vaclavholusa commented 2 years ago

They are used for validating requested movements or loading additional data for the actual handler. And they are usually share among multiple pipelines. It’s a nice separation of concerns when perform validations (like can this bin be moved to this place) and we load neccessary data in the behaviors so the actual handler can just perform the actual movement for example. It perfectly suits the needs there are in the project. Also given the fact that they are shared I see this usage of behaviors very very powerful.

ronnieholm commented 2 years ago

I suppose the alternative would be creating application or domain services (assuming you're using DDD), but sounds like you weighed the pros and cons for your specific case. Typically I have AuthorizationBehavior, LoggerBehavior, PerformanceBehavior, UnhandledExceptionBehavior, and ValidationBehavior. I never considered creating behaviors which are cross-cutting for only a subset of requests.