c# - net - MediatR ¿Cuándo y por qué debería usarlo? vs 2017 webapi
github asp net core eshop (2)
Se podría haber preguntado antes, pero no puedo encontrar ni siquiera en el sitio oficial por qué debo usar MediatR y qué problemas resuelve.
¿Es porque puedo pasar un solo objeto en mi constructor en lugar de una multitud de interfaces?
¿Es un reemplazo o competidor de ServicesBus, etc ...
Básicamente, ¿cuáles son los beneficios y qué problema resuelve?
Quiero comprarlo pero no me queda claro por qué debo usarlo.
muchas gracias
¿Es porque puedo pasar un solo objeto en mi constructor en lugar de una multitud de interfaces?
No.
¿Es un reemplazo o competidor de ServicesBus, etc ...
No.
Básicamente, ¿cuáles son los beneficios y qué problema resuelve?
Entre otras cosas, uno de los problemas que MediatR está tratando de resolver es la explosión del constructor DI en sus controladores MVC.
public DashboardController(
ICustomerRepository customerRepository,
IOrderService orderService,
ICustomerHistoryRepository historyRepository,
IOrderRepository orderRepository,
IProductRespoitory productRespoitory,
IRelatedProductsRepository relatedProductsRepository,
ISupportService supportService,
ILog logger
)
Este es un tema muy debatido y no existe una solución única para todos, eche un vistazo a esta pregunta
¿Cómo evitar la dependencia del constructor de inyección de dependencia?
Si desea ocultar las dependencias detrás de aún más abstracciones, en este punto querrá echar un vistazo a todas las opciones, como refactorizar, separar preocupaciones un poco más u otras técnicas.
Con toda honestidad, el problema de ejemplo y la solución que se dan en el sitio web de MediatR es un poco sospechoso, pero tiene sus usos . En resumen, debe elegir lo que es correcto para usted y su entorno.
Resumen del patrón de mediador
Un mediador es un objeto que toma decisiones sobre cómo y cuándo los objetos interactúan entre sí. Encapsula el "cómo" y coordina la ejecución según el estado, la forma en que se invoca o la carga útil que le proporciona.
En relación con el espíritu de su pregunta, debería echar un vistazo a este sitio.
Simplificando el desarrollo y separando las preocupaciones con MediatR
MediatR es una implementación de código abierto del patrón de mediador que no intenta hacer mucho y no realiza magia. Le permite redactar mensajes, crear y escuchar eventos usando patrones síncronos o asíncronos. Ayuda a reducir el acoplamiento y aísla las inquietudes de solicitar el trabajo a realizar y crear el manejador que despacha el trabajo.
Más sobre el patrón de mediador
¿Puede describir en su propia opinión por qué lo usaría?
El patrón de mediador ayuda a decoupling su aplicación a través de la comunicación a través de un mediador (es una cosa).
Por lo general, un programa se compone de un gran número de clases. Sin embargo, a medida que se agregan más clases a un programa, el problema de la comunicación entre estas clases puede volverse más complejo. Esto hace que el programa sea más difícil de leer y mantener. Además, puede resultar difícil cambiar el programa, ya que cualquier cambio puede afectar al código en otras clases.
Con el patrón de mediador, la comunicación entre objetos se encapsula dentro de un objeto mediador. Los objetos ya no se comunican directamente entre sí (desacoplamiento), sino que se comunican a través del mediador. Esto reduce las dependencias entre objetos que se comunican, reduciendo así el acoplamiento.
En el software moderno, el patrón de mediador generalmente se encuentra en muchos marcos, sin embargo, puede crear el suyo propio o usar uno de los muchos disponibles.
A partir de aquí, creo que probablemente debería hacer más investigación, me refiero a que generalmente se da cuenta de que necesita estas cosas antes de investigarlas; sin embargo, en este caso, creo que realmente necesita encontrar algunos buenos ejemplos para saber si desea el patrón de mediadores. , y aún más la biblioteca MediatR
Actualizar
wired_in tenía un gran comentario práctico sobre esto
Todo lo que MediatR hace es localizar un controlador para una solicitud. Ese no es el patrón mediador. El "mediador" en este caso, no describe cómo se comunican dos objetos, utiliza la inversión de control que ya se está utilizando en una aplicación y solo proporciona una capa de abstracción inútil que solo sirve para hacer que una aplicación sea más difícil de razonar como una todo. Usted ya logra el desacoplamiento mediante el uso de una inyección de constructor estándar con IoC. No entiendo por qué la gente compra esto. Vamos a crear múltiples raíces compuestas para no tener que poner interfaces en nuestro constructor.
y
El OP está completamente justificado al cuestionar el punto de MediatR. Las respuestas principales que escucho a la pregunta involucran la explicación del uso del patrón de mediador en general, o que hace que el código de llamada sea más limpio. La explicación anterior asume que la biblioteca MediatR implementa el patrón de mediador, que está lejos de ser claro. La última no es una justificación para agregar otra abstracción sobre un contenedor IoC ya abstraído, que crea múltiples raíces compuestas. Simplemente inyecte el controlador en lugar del servicio localizándolo
Es solo una forma de implementar la comunicación entre los componentes de la lógica de su negocio.
Imagina que tienes:
FirstRequest // which handled by FirstRequestHandler(FirstRequest)
SecondRequest // which handled by SecondRequestHandler(SecondRequest)
ThirdRequest // which handled by ThirdRequestHandler(ThirdRequest)
... Hay cientos de ellos ...
Y luego viene ComplexRequest, cuando ComplexResponse tiene que ser una combinación de FirstResponse y ThirdResponse.
¿Cómo deberíamos resolver esto?
Bueno, ComplexRequestHandler tendría que inyectar FirstHandler y ThirdHandler, obtener sus resultados y combinarlos.
Pero, ¿por qué debería ComplexRequestHandler tener acceso a la interfaz de FirstRequestHandler? ¿Por qué deberíamos molestarnos en inyectarnos Primero, Tercero ... Cien y Veinte Manejadores en nuestro Handler Complejo?
Lo que MediatR nos brinda en tal caso de uso, es un tercero que nos dice: "Dame una solicitud y te daré la respuesta correcta, ¡Confía en mí!"
Así que ComplexHandler no sabe nada acerca de First and Third Handlers. Solo conoce las solicitudes y respuestas requeridas (que normalmente solo están envolviendo DTO).
Nota: No tiene que usar necesariamente la biblioteca MediatR para eso. Puede leer sobre el patrón de mediador e implementar uno mismo.