{"id":28,"date":"2024-03-15T11:14:00","date_gmt":"2024-03-15T14:14:00","guid":{"rendered":"https:\/\/dumba.dev.br\/?p=28"},"modified":"2026-01-13T11:28:26","modified_gmt":"2026-01-13T14:28:26","slug":"vai-um-mediatr-ai","status":"publish","type":"post","link":"https:\/\/dumba.dev.br\/index.php\/2024\/03\/15\/vai-um-mediatr-ai\/","title":{"rendered":"Vai um MediatR ai?"},"content":{"rendered":"\n

Na maioria das vezes que vejo projetos utilizando Microsservi\u00e7os em .NET os arquitetos gostam de usar CQRS com o Mediator. Virou quase um default<\/strong> para utiliza\u00e7\u00e3o desse padr\u00e3o. E para utilizar o padr\u00e3o Mediator<\/strong><\/a> faz o uso do famigerado pacote MediatR.<\/p>\n\n\n\n

Na minha humilde opini\u00e3o, est\u00e1 ai uma mistura complexa e atualmente mal utilizada (N\u00e3o me mate). Mas fica para um pr\u00f3ximo artigo.<\/em><\/p>\n\n\n\n

O que \u00e9 o pacote MediatR?<\/h3>\n\n\n\n

O MediatR \u00e9 um componente criado por JBogard o mesmo cidad\u00e3o que criou o AutoMapper. Calma, n\u00e3o julgue ainda… o AutoMapper funciona! Tudo depende do contexto. \ud83d\ude00<\/p>\n\n\n\n

Voltando….<\/em><\/p>\n\n\n\n

O MediatR implementa um padr\u00e3o muito top chamado Mediator. N\u00e3o faz parte desse artigo explicar o que \u00e9, mas diz o seguinte.<\/p>\n\n\n\n

\n

O Mediator \u00e9 um padr\u00e3o de projeto comportamental que permite que voc\u00ea reduza as depend\u00eancias ca\u00f3ticas entre objetos. O padr\u00e3o restringe comunica\u00e7\u00f5es diretas entre objetos e os for\u00e7a a colaborar apenas atrav\u00e9s do objeto mediador.<\/p>\n<\/blockquote>\n\n\n\n

Por que voc\u00ea gosta?<\/h3>\n\n\n\n

Para mim, a implementa\u00e7\u00e3o do padr\u00e3o Mediator \u00e9 perfeita, fazendo com que o acoplamento do c\u00f3digo seja m\u00ednimo. Com pouca configura\u00e7\u00e3o ja se consegue algo muito interessante. Segue o reposit\u00f3rio oficial – https:\/\/github.com\/jbogard\/MediatR.<\/p>\n\n\n\n

Gosto do uso fazendo com que o Handler seja minha camada de servi\u00e7os de aplica\u00e7\u00e3o ou casos de uso do projeto, fazendo com que para cada mudan\u00e7a de estado “Commands” seja separado por objetos diferentes. Cada a\u00e7\u00e3o com seu Handler com as regras de orquestra\u00e7\u00e3o.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Assim para cada contexto de atualiza\u00e7\u00e3o do estado de um dom\u00ednio eu tenho um Command<\/strong>, um Handler<\/strong> e um Response<\/strong> diferente.<\/p>\n\n\n\n

Uma outra situa\u00e7\u00e3o interessante \u00e9 quando podemos ter eventos ap\u00f3s qualquer mudan\u00e7a no sistema. Nesse mesmo projeto ao criar um Pedido deve – se lan\u00e7ar uma notifica\u00e7\u00f5es a algumas pessoas. Nesse caso, somente enviamos um Evento e o MediatR faz o papel de entregar ao handler ou handlers de evento correto. Funciona muito bem para disparar eventos a outros Microsservi\u00e7os ou Contextos.<\/p>\n\n\n\n

O uso correto faz com que se tenha um ganho de desacoplamento muito interessante.
Somente fazendo um parentese, eu n\u00e3o gosto do uso para Queries no caso do CQRS, uso direto mesmo com uma ServiceQuery ou QueryRepository. Simplifica a vida.<\/em><\/p>\n\n\n\n

Por que virou zona?<\/h3>\n\n\n\n

Assim como o uso de Microsservi\u00e7os em toda solu\u00e7\u00e3o existente o MediatR n\u00e3o ficou de fora. Virou modinha.<\/p>\n\n\n\n

Vejo algumas implementa\u00e7\u00f5es um tanto estranhas com MediatR.<\/p>\n\n\n\n