In this case, you might want to look at NServiceBus, Brighter, MassTransit, Rebus. This is where out-of-process messaging comes in. You want event/notification handlers to be run in independently in isolation. How do you want to handle this? Can you re-publish that message again and have the handlers that succeeded run again? What if one of them was sending an email? That exception will bubble up back to where you published the message via MediatR. But what happens if one of them fails and throws an exception? In the example above, if you publish a notification to MediatR, and there are 3 handlers for that notification, it will execute all 3. However the execution of all the notification handlers are done all in the same process. With everything in-process, this becomes really apparent with Events/Notifications (MediatR calls them Notifications).Ī notification can have zero or multiple handlers. Udi Dahan the founder of NServiceBus posed this question on Twitter with my response. Meaning that wherever process is calling mediator.Send() is also the same process that is executing the relevant Handler for that request. The reason you may not want to use MediatR is simply that everything is done in-process. This is incredibly powerful and allows you to separate different concerns related to a given application request. This means you could have any number of pre-processors that can be run prior to the primary handler, or post-processors that can be run after. This allows us to do primary work before calling it or possibly even short-circuiting and not calling it at all, say if we had some validation issues. The RequestHandlerDelegate which is a delegate to call PlaceOrderHandler. When you call mediator.Send() this behavior is called first prior to your primary handler ( PlaceOrderHandler). There are a few different ways to create them but here’s an example of a that implements the IPipelineBehavior You can create the same concept using MediatR behaviors. If you’re familiar with ASP.NET Core middleware, the purpose is to define a pipeline for an HTTP request. Once you start thinking about application requests, you can go deeper into creating a pipeline for those requests. Using MediatR to create application requests to cross an integration boundary. That Application request is entirely decoupled from any specific top level framework and could be invoke from anywhere. In my example above with ASP.NET Core, we’re ultimately converting an HTTP request into an Application Request. There are a number of ways that you may want to invoke behaviors in your system that don’t initiate from an HTTP request. Or you may also have work that gets triggered from specific messages you’re picking up from a Message Broker. There may be various ways that interact with your application.įor example, you could have recurring jobs that need to perform specific actions at a given time during the day. Not all incoming requests are going to be via HTTP. There’s a difference between a web application and just an application.Īn application can have many different inputs. The reason why decoupling from top-level framework code such as ASP.NET Core can be important is to ask yourself: Is the application I’m creating an application or a web application? The PlaceOrderHandler has no references to any types or APIs in ASP.NET Core. The point is creating a request object that you pass to MediatR which in turn invokes the correct Handler for that request object.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |