Todos nuestros sistemas se parecen, unos llevan determinados módulos, otros no. Por eso, siempre he estado pensando la forma de hacerlos modulares de forma que sea fácil quitar o poner módulos de un sistema a otro, cada uno con su configuración. Cuando me puse a pensar en ello llegué a la conclusión de que sería buena idea hacer que cada módulo fuera un jar, independiente de los otros. Luego, en un sistema, es cuestión de instanciar y configurar aquellos módulos que nos interesen, trayendo sólo los jar necesarios.
Puesto que los módulos interaccionan entre ellos y cuando uno de ellos quiere hacer algo normalmente necesita datos de otro módulo, o a veces cuando un módulo genera algo necesita avisar a los otros para que sigan el proceso, también me puse a pensar en ello. Una especie de mecanismo de suscripción de eventos, de forma que en algún sitio cerca del main, donde se instancian y configuran módulos, también se hicieran suscripciones a determinados eventos de un módulo y se avisara de ellos a los otros módulos.
Afortunadamente, antes de ponerme a codificar algo como esto, se me ocurrió investigar por internet y me encontré con los contenedores de inversión de control y en concreto con Spring Framework. Aunque el framework está muy pensado para aplicaciones web, está bien diseñado y puedo bajarme y usar sólo el núcleo, lo que me permite a través de ficheros XML instanciar los distintos módulos, configurarlos y hacer que se vean unos a otros. También me proporciona un sistema de publicación y suscripción de eventos entre módulos. Justo lo que quería.
Así que como suelo hacer en estos casos, cogí a un grupo de gente afín a mis ideas peregrinas, les conté lo fácil y bien que podiamos usar Spring Framework en nuestras aplicaciones y lo usamos en uno de los proyectos que empezaban. La experiencia fue buena y todos quedamos bastante contentos en general, así que decidimos ir aplicándolo a más proyectos.
Pero al empezar a usarlo en más proyectos e involucrar a más gente, empecé también a encontrar más oposición y otros puntos de vista. Un compañero mío más crítico que yo con las innovaciones comentó que "Spring no es más que una forma "friky" de hacer news". No obstante, él también andaba buscando una forma de configurar con ficheros sus módulos, ya que se ve repitiendo código de configuración prácticamente igual de un proyecto a otro.
Y el otro día sucedió algo que me ha hecho empezar a dudar de la utilidad de Spring Framework, al menos usando sólo el núcleo y en aplicaciones de escritorio. Este compañero en uno de los proyectos en los que tiene cierta responsabilidad me dijo que se estaban instanciando en Spring dos módulos iguales con configuración distinta, pero que habían cambiado los requisitos y debíamos eliminar uno de ellos y cambiar el otro por un tercero distinto. Nos pusimos a ello.
Borrar uno de los módulos es fácil, sólo hay que ir borrando las referencias en los ficheros XML y en algunos sitios muy concretos del código. Cambiar el otro fue algo más complejo, buscarlo para reemplazarlo, cambiar nombre de clases, parámetros a inicializar, buscar referencias para ver si son compatibles, etc, etc. Una vez que creímos todo estaba hecho, arrancamos la aplicación y nos saltan un par de errores, nos habíamos equivocado en el paquete de una de las clases de un bean de Srping Framework. Más cambios, nueva prueba y nuevo fallo. Esta vez, a la tercera fue la vencida y todo funcionando. Pero mi compañero hizo el comentario que me metió la duda en el cuerpo: "Si en vez de hacer los news y la configuración en ficheros XML los hubieramos hecho en código, todo esto habría cantado en el mismo IDE. Prefiero ver los errores mientras escribo que verlos después arrancando la aplicación".
Y tiene razón, hacer news y configurar en XML tiene la pega de que errores que se verían inmediatamente mientras escribes en el IDE (un new de una clase que no existe por ejemplo, o la llamada a un set para configurar algo) no los vemos hasta que arrancamos la aplicación.
Hay un plugin para eclipse que permite ver si lo que escribes en el XML de Spring es correcto (las clases existen, los métodos existen, etc), pero no lo tenía instalado y lo de que hayan cogido Spring los de SpringSource, me da "mal rollo", parece que se quieren dedicar a cobrar por dar cursos y que este tipo de plugins o incluso las descargas están cada vez más escondidas previo registro.
Instalaré el plugin, miraré la posibilidad de hacer un test de JUnit que verifique que un XML de Spring es correcto y a ver qué pasa. De todas formas, empiezo a pensar que sólo para hacer news no merece la pena. Me queda el tema de los eventos al que sí sacamos partido….
Pingback: de la red – 21/06/2010 « Tecnologías y su contexto
Bueno justo lo que grails intenta eliminar es el xml de las configuraciones de los framework que utiliza, utilizando codigo groovy para las configuraciones, que no «canta» tanto como java (aunque cada vez mas a medida que las ides tienen en cuenta el aspecto dinamico de estos lenguajes) Groovy + Griffon podria ser la alternativa.
Por otra parte se puede utilizar el patron de inyeccion de dependencia sin ningun framework (en realidad es algo bastante simple en su esencia) o utilizando http://code.google.com/p/google-guice/ que usa anotaciones en lugar de xml.
Aunque grails tampoco te convencia… 😛
Pingback: Tweets that mention Diario de Programación » Blog Archive » Mis dudas con Spring para aplicaciones de escritorio -- Topsy.com
Bueno… grails no me convencía en mi primera aproximación, pero soy consciente de que posiblemente muchos problemas eran causados por mi desconocimiento y falta de experiencia. Es muy probable que cualquier día me de por probar otra vez y en concreto me llama la atención lo de Griffon … que es para aplicaciones de escritorio ¿verdad?
Y sí, lo de inyección de dependencia directamente en código (sin anotaciones, a base de news y sets) es más o menos lo que hacíamos antes de probar con Spring, por lo que el paso a Spring no fue demasiado costoso.
Se bueno.
No soy ningún experto en Spring, pero eso de que solo sirve para no hacer News…
Desde el punto de vista más «teórico» de entrada sirve para llevar la idea de programar contra interfaces en lugar de contra clases a su máximo exponente. Las clases nunca llegan a conocerse y eso puede ser muy útil en algunos casos. Lo típico, tienes que des/encriptar un dato y tienes varias opciones SHA, MD5… Basta con cambiar la referencia al bean que inyectas (si las dos clases de encriptación tienen implementadas una interfaz común) para decidir con que trabajas. No necesitas re-compilar nada, basta modificar un XML.
Además, Spring al trabajar con una única instancia por defecto de cada clase, hace que la aplicación sea algo más eficiente al no crear más objetos de los necesarios. Está claro que esto también tiene su lado negativo y es que si no se tiene cuidado puede acabar la cosa en problemas de concurrencia (alguna vez ya me ha pasado).
Más ventajas: que Spring sea el encargado de crear objetos da mucho juego, por ejemplo da pie a los interceptores. Jugando con los interceptores se puede conseguir de una forma muy elegante cosas como auditar una acción ejecutada en un método o securizarlo.
En cualquier caso, a mi lo que más me gusta de Spring es la integración con algunos otros Frameworks que ya trae. Se acabó lo de andar abriendo y cerrando transacciones con bases de datos y controlando errores para hacer rollback, con una simple configuración y él ya se encargará de todo esto.
En definitiva, creo que ofrece muchas cositas interesantes ahorrándonos el tiempo de desarrollarlas nosotros, aunque lógicamente si solo se usa para inyectar dependencias pues su utilidad se reduce drásticamente.
Bueno, lo de las interfaces depende cómo lo programes, Spring no te ayuda más que si lo haces desde código ni te obliga, con o sin Spring, es cosa tuya poner las interfaces y hacer que los objetos interactuen a través de ellas. Lo de la instancia única por clase tampoco es realmente una ventaja de Spring, ya que en Spring puedes instanciar una clase tantas veces como quieras o decir que sea instancia única, como podrías hacerlo desde código. Te ahorras escribir el código del Singleton.
En cuanto a lo de las demás frameworks, sí tienes razón, es una asignatura que tengo pendiente. He hecho algo con Spring y los Daos de iBatis, pero no demasiado en serio. También veo que tiene muy metido el tema de orientación a aspectos, tengo que investigarlo un poco en serio para ver si nos puede ser útil (entiendo que son los interceptores que comentas). Y veo también que habla mucho de los test automáticos con Spring, es otra cosa que tengo que investigar.
Se bueno.
De la forma en la que describes el problema que tuvieron con Spring, los modulos, pareciera que no son tan «independientes». Pero si no usaras Spring, tendrias problemas diferentes en el codigo. Usar un framework u otro o no usar ninguno, tiene sus ventajas y desventajas. Has intentado usar Guice, la liga que pone atreyu http://code.google.com/p/google-guice/ realmente ofrece una alternativa a Spring para implementar DI. En la pagina viene un video interesante, te podria dar algunas ideas.
Bueno, el problema aparte de que los módulos sean dependientes o no, es que al hacer news y set con XML puedes equivocarte en nombres de clases, de beans o de params y no obtendrás el error hasta el momento de ejecutar. Si haces esos news y set en código, el mismo IDE te avisará en cuanto lo escribas mal, antes incluso de compilar. La detección temprana de errores siempre es un punto.
La ventaja de Spring (u otro framework) es que te suele dar muchas cosas hechas y te da uniformidad a la hora de hacerlas. En el caso de hacer news en xml, no te ahorra demasiado trabajo (haces en xml los news y set que te ahorras en código), pero te da la uniformidad de que sabes dónde están los news y los sets. Si los haces en código, lo más probable es que no haya un sitio estándar para hacerlo o incluso que los diferentes news y set estén repartidos por varias partes del código, salvo que en tu grupo haya una disciplina muy estricta.
Se bueno.
Chuidiang , y cual es el nombre del plugin que mencionas? el que te dice de los errores en los beans en el applicationContext.
Saludos desde Monterrey, Mexico.
El plugin creo recordar es Spring IDE http://marketplace.eclipse.org/content/spring-ide
Se bueno.
java nativo no soporta módulos, para ello existen se puede decir simuladores como: OSGI http://www.osgi.org/Specifications/HomePage
GOOGLE-GUICE http://code.google.com/p/google-guice/
para ínterconectar los módulos puedes usar WebService
Yo hace poco estoy incursionando en el mundo de spring y la verdad te digo que te ahorra muchos dolores de cabeza a la hora de programar aplicaciones distribuidas o webs. El verdadero potencial de spring esta en que es un contenedor liviano (lightweight container) y podemos crear aplicaciones tan «robustas y potentes» como una JavaEE sin necesidad de gastar tanto en un servidor de aplicaciones, por otro lado spring te «obliga» a llevar buenas costumbres a la hora de encarar un proyecto y la forma en que programamos. La verdad que mucho jugo no se le puede sacar implementandolo en aplicaciones de escritorio.