jbogard / MediatR

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

MVC client consuming Web API with MediatR implementation #72

Closed prav-raghu closed 7 years ago

prav-raghu commented 8 years ago

How would one consume an ASP Web API service that makes use of Request(Query) and Response(Result) - Web API that implements MediatR - that can be strongly typed to class instances? To Simplify, if I have a Request Model in my web API that "passes" data to my handler, would a view model in a project such as a standard ASP MVC project need to follow the same structure; for example: if the Request model (or a Query in this case) is being passed to the handler and has a property of an ID of type integer, would the front end client application that has a view model need to follow the same structure of the request being pushed through; in that the view model in mention should also have a property of an ID that is of type integer, and in doing so won't this result in replication of code? (the view model trying to match up with the query/request). With Reference to article: https://lostechies.com/jimmybogard/2015/05/05/cqrs-with-mediatr-and-automapper/

ThisNoName commented 8 years ago

If MVC calls WebApi, it's just a regular restful api call. It has to follow whatever the api exposed.

On the Api side, you do have a choice of exposing MediatR request, or use primitive type. With request, it's easier to validate and you can pass request directly to handler. But you could end up with some ridiculous request like UserIdRequest { int Id } . It also forces some non-restful convention onto consumers, I think.

If you expose primitive type, like User (int id), the interface is more natural. But you have to manually create request before send. There also seems no easy way to validate primitive type on controller method.

Most updates are probably done using Post with complex type, in that case, you do expose MediatR request. You can share dll, create documentation, generate proxy class, etc.

I really wish the framework can automatically wire up all requests as controllers though, save tons of boilerplate work.