Me he estado rascando la cabeza desarrollando una arquitectura sencilla basada en plugins encima de Spring, para una de mis aplicaciones actuales. No importa la cantidad de separación que uno pueda lograr usando patrones como MVC, siempre se llega a un punto donde el acoplamiento es inevitable.Desarrollar una arquitectura basada en complementos en la parte superior de Spring
Por lo tanto, comencé a pesar las opciones. Al principio pensé que los filtros son buenos. Cada complemento que haría sería un filtro, que luego simplemente insertaré en el mapa del filtro. Por supuesto, esto creará un poco de sobrecarga al enumerar y verificar todos los filtros, pero al menos, a los controladores no les tendrá que importar qué pasó con los datos antes de que lleguen a ellos, o lo que ocurra después, simplemente les importará. buscar los modelos (a través de DAO o lo que sea) y devolverlos.
El problema con esto es que no todas mis solicitudes de aplicaciones están basadas en HTTP. Algunos se basan en correos electrónicos, otros están programados internamente (cronometrados), por lo que los filtros no ayudarán mucho, a menos que intente adaptar todo tipo de solicitudes entrantes a HTTPRequest, lo cual sería demasiado.
Otro en el que pensé fue en AOP basado en anotaciones, donde anoto cada método, donde el plugin interceptaría métodos basados en ciertas convenciones. Mi problema es que primero no tengo tanta experiencia con AOP en general, y segundo, simplemente escribir todas esas convenciones ya sugiere un poco de acoplamiento
De lejos, la opción que más apela a mi forma de pensar es usar Spring- eventos basados Cada tipo de controlador de solicitudes dentro de mi aplicación (controlador web, manejador de correo electrónico, etc.) será una especie de despachador de eventos, que enviará eventos de primavera en cada acción importante. Por otro lado, los complementos simplemente escucharán cuándo ocurre un evento en particular y harán algo de lógica. Esto me permitirá utilizar también el punto 1, ya que algunos de esos complementos también podrían ser filtros, es decir, cuando reciben una notificación de que se realiza una determinada acción del controlador, pueden decidir no hacer nada, y esperar cuando ellos son llamados por la cadena de filtros. Veo esto como un enfoque algo agradable. Por supuesto, aquí viene la sobrecarga otra vez, de enviar eventos, más el hecho de que todas las clases involucradas se combinarán con Spring para siempre, pero veo esto como un mal necesario.
Mi principal preocupación con respecto a los eventos de primavera es el rendimiento, tanto en términos de latencia, y la huella de memoria.
Todavía no soy un experto, por lo que un montón de comentarios aquí sería de gran ayuda. ¿Los eventos de primavera son los mejores para este tipo de arquitectura, o hay otra solución que me he perdido? Soy consciente de que incluso podría haber soluciones de terceros, así que me alegraría que alguien pudiera señalar una o dos de las probadas.
Gracias.
Por muy interesante que sea esta pregunta, diría que está totalmente fuera de tema aquí y voy a votar para cerrarla como "No constructiva" (lea la definición y probablemente esté de acuerdo). Creo que los foros de primavera/listas de correo son el lugar para hablar sobre esto. –
No veo por qué esta pregunta no es constructiva o fuera de tema en absoluto. –