Ahora que se puede pedir la muerte de los monarcas en impunidad, yo también me voy a unir a la moda y voy a pedir la muerte de otro rey: “¡Muerte al if!”
Nota: Que conste que no estoy entrando en el fondo (ni en la forma) sobre el asunto de Joan Tardà, que no se vaya a molestar nadie…
Pues bien, a lo que iba, hace ya unas semanas hice una breve referencia a la campaña anti-if a la que me adherido tal y como reza un anuncio en el lateral de este blog. Os recomiendo encarecidamente la siguiente entrada del blog de Miško Hevery titulada “Inheritance, Polymorphism, & Testing” (sí, lo siento, en inglés) porque no tiene desperdicio. Tranquilos, si no os queréis “chupar” la media hora larga de presentación, también están las diapositivas. Por cierto, ahí está la respuesta a cómo se resuelve el segundo ejercicio del TestFirstChallenge que he usado en algunas ocasiones para enseñar TDD e incluso para seleccionar candidatos en una empresa donde trabajaba antes (no diré cuál para no dar pistas).
Por cierto, antes de que se me olvide, ¿alguno de vosotros usa Guice? Estaría bien que contárais la experiencia, sobre todo si la podéis comparar con Spring. ¡Sería genial!
Nota: Que conste que no estoy entrando en el fondo (ni en la forma) sobre el asunto de Joan Tardà, que no se vaya a molestar nadie…
Pues bien, a lo que iba, hace ya unas semanas hice una breve referencia a la campaña anti-if a la que me adherido tal y como reza un anuncio en el lateral de este blog. Os recomiendo encarecidamente la siguiente entrada del blog de Miško Hevery titulada “Inheritance, Polymorphism, & Testing” (sí, lo siento, en inglés) porque no tiene desperdicio. Tranquilos, si no os queréis “chupar” la media hora larga de presentación, también están las diapositivas. Por cierto, ahí está la respuesta a cómo se resuelve el segundo ejercicio del TestFirstChallenge que he usado en algunas ocasiones para enseñar TDD e incluso para seleccionar candidatos en una empresa donde trabajaba antes (no diré cuál para no dar pistas).
Por cierto, antes de que se me olvide, ¿alguno de vosotros usa Guice? Estaría bien que contárais la experiencia, sobre todo si la podéis comparar con Spring. ¡Sería genial!
#1 by Herme Garcia on 9 de December, 2008 - 23:02
Hola Jose Manuel,
Nosotros hemos utilizamos los dos Spring y Guice, aunque últimamente estamos decantándonos más por Guice.
Una breve comparativa:
* Spring es enorme y hace muchas cosas, guice muy sencillito y basicamente hace IOC.
* Con Spring tienes solucionada la integración con muchisimos paquetes (Hibernate, iBatis, Quartz, Spring MVC) y clases de ayuda con muchas tecnologias (JDBC, JPA, JMX), dos ayudas dignas de mencionar es el @Transactional y el framework que tiene para pruebas (compatible con JUnit y con TestNG)
* Con Guice no tienes nada de eso, solamente tienes IOC, pero a veces es una gran ventaja, ya que a veces es dificil ocultar y aislarte de todo lo que no usas o no quieres usar.
* Con Spring resuelves los ficheros de configuracion de tu software, los archivos xml de configuracion de Spring son fantásticos, con un namespace propio puedes utilizalos no solamente para el wiring de tu aplicacion sino tambien para tu configuracion, hay muchos paquetes cuya configuracion es simplemente la configuracion de Spring, por ejemplo Mule lo usa.
* Con Guice no hay ficheros de configuracion , simplemente hay una clase que extiende Module.class que define el wiring, lo bueno de esto es que no tienes complicaciones con el classpath cuando ejecutas tu programa en diferentes entornos (p.ej. deployment y test de integracion) y que es muy sencillo en guice tener muchos modulos de wiring diferentes.
* El Spring tiene un plug-in de Eclipse, sencillamente genial, con refactorizacion, con chequeo de sintaxis, con auto-completion para todo (mas allá del xsd), y funciona muy bien, sin bugs.
* El Guice no tiene plugins, aunque como la configuración es código Java, el propio Eclipse lo chequea.
Desde mi punto de vista, el Guice esta muy bien cuando el software que estamos desarrollando tiene un wiring fijo y básico, que normalmente cambiamos cuando cambiamos el propio código, como es el caso de la mayoría de los programas, es muy sencillo de entender, de depurar y nos ayuda a escribir buen código, y el Spring, se puede recomendar cuando el wiring y la configuracion es la base del programa, por ejemplo cuando hablamos de sistemas de infraestructura que se van a utilizar en varios entornos diferentes y cuya configuracion cambia muy a menudo, en ese caso el Spring nos da una enorme flexibilidad, nosotros solamente hemos de desarrollar los beans, que son simples POJOs.
A tu disposición, un saludo
#2 by Jose Manuel Beas on 10 de December, 2008 - 03:26
Muchas gracias por la comparativa, Herme. Sencillamente excelente.