Arquitectura para la extensión / comunicación de plugins.

Una vez que se resuelve el problema de cargar complementos (en .NET a través de MEF en el caso de salida), el siguiente paso para resolver es la comunicación con ellos. La forma más sencilla es implementar una interfaz y usar la implementación del complemento, pero a veces el complemento solo necesita extender la forma en que funciona la aplicación y puede haber muchos puntos de extensión.

Mi pregunta es sobre cómo lidiar con esos puntos de extensión. He visto diferentes formas de hacerlo pero no estoy seguro de los pros y los contras de cada uno y si hay más y mejores formas de lograrlo:

Eventos: agregando eventos estáticos a todas las cosas que queremos hacer "extensibles". Por ejemplo, si quiero agregar una validación personalizada para una clase de usuario, puedo agregar un controlador de eventos estáticos OnValidation y agregarle eventos desde el complemento cuando se construya.Mensajería: Tener un bus y unos mensajes. El complemento puede suscribirse a un mensaje en particular y hacer cosas cuando alguna otra clase publica ese mensaje. El mensaje debe contener el contexto en el que puede funcionar el complemento. En el caso de validación, la capa lógica publicará un mensaje de Validación de Usuario y el complemento actuará cuando se reciba el mensaje.Interfaces: la aplicación host es responsable de llamar a todos los complementos que implementan ciertas interfaces y les dan el contexto de la operación actual. En el caso de la validación, el complemento puede implementar un IValidator o IUserValidator con un método Validate (contexto de objeto).

¿Alguna vez ha utilizado uno de los enfoques expuestos? ¿Cuál funcionó mejor para ti?

Y antes de que pregunte, nuestra aplicación es un núcleo extensible (usuario, gestión de contenido y contenido) para construir nuestras aplicaciones web centradas en el contenido específicas del cliente además de eso. Todo construido en ASP.NET MVC.

Respuestas a la pregunta(2)

Su respuesta a la pregunta