Pico vs. Spring

Hace mucho que quería escribir esto, pero por una razón u otra lo fui posponiendo, pero ahora que finalmente reemplacé Pico por Spring en la aplicación, creo que es un buen momento.

El proyecto en el que vengo trabajando hace mas de un año, usaba originalmente Picocontainer como container de dependency injection (DI). La razón, sin entrar mucho en detalles, fue que la persona que actuaba como arquitecto en ese momento, es uno de los commiters del proyecto Pico, y por lo tanto lo impuso a pesar que el resto del equipo se inclinaba por Spring, con el que ya teníamos experiencia previa (como comentario al margen, tampoco nos dejó usar Java 5…).

En primer lugar, aclaremos que Pico cumple su cometido impecablemente. Provee DI a una aplicación web sin problemas,  provee  constructor  injection o  setter injection (aunque esta última vaya uno a saber como se hace). Para  poder externalizar  la configuración a un XML externo, o bien a un script Groovy o Jyton, hay que usar Nanocontainer, otro paquete de los mismos autores.  Hasta aquí todo muy bien, pero la pregunta es, por qué un proyecto debería usar Pico en lugar de Spring? Qué tiene mejor Pico que Spring, o que ofrece Pico que no pueda ofrecer Spring?

Veamos un poco en detalle:

Pico es muy “liviano”.

Es cierto, el tamaño de los .jar de Pico + Nano + Nanowar apenas pasa los 300Kb, mientras que el paquete completo de Spring son mas de 2Mb. Sin embargo, Spring también se distribuye en varios .jar separados y uno puede elegir deployar solo lo que uno va a usar. Pero en el peor de los casos, cuál es el problema para una aplicación que corre siempre en un mismo server? Quizá el deployment que hago una vez por semana tarde 20 seg. mas.

Pico provee constructor injection.
Si bien la gente de Spring promueve setter injection, a diferencia de la de Pico que promueve constructor injection (no me voy a explayar en esto, cada uno tiene sus méritos), no significa que que Spring no soporte constructor injection. De hecho, lo soporta mejor que Pico, paso a explicar:
Por default, Pico trabaja con autowire, lo que significa que automágicamente descubre que beans tiene que inyectar según el tipo de los beans y los tipos definidos en el constructor. Pico enfatiza mucho este aspecto, porque según ellos ayuda a mantener el XML de configuración en un tamaño reducido. Por ejemplo, si tenemos la siguiente clase:

package com.sarcobjects.persistence.hibernate;

public class HibernateGamePersister     extends HibernatePersisterSupport     implements GamePersister, Serializable {

    public HibernateGamePersister(SessionFactory factory) {
        super(factory);
    }
    …
}

El constructor necesita una instancia de la clase SessionFactory. Entonces, este fragmento de XML es suficiente para configurarlo:

<component-implementation class=’com.sarcobjects.persistence.hibernate.SessionFactory’ />
<component-implementation class=’com.sarcobjects.persistence.hibernate.HibernateGamePersister’/>

Pico descubre que el tipo que necesita inyectar es SessionFactory, lo busca en el XML y si lo encuentra lo inyecta.
El equivalente en Spring sería:

<bean id=”gamePersister” class=’com.sarcobjects.persistence.hibernate.HibernateGamePersister’ autowire=”constructor”/>

La diferencia es que le tengo que agregar autowire=”constructor” porque para Spring el default es setter injection.
Hasta acá todo muy lindo, pero el problema aparece cuando le tengo que pasar además, por ejemplo,  una constante, o bien el archivo de configuración contiene mas de una definición del mismo tipo.  Ahí ya pierdo todo lo automágico y no me queda mas remedio que explícitamente definir que quiero inyectar. Por ejemplo:

<component-implementation class=”com.sarcobjects.web.admin.dashboard.QuartzDashboardScheduler”>
    <parameter key=”service” />
    <parameter key=”factory” />
    <parameter key=”gameStatus” />
    <parameter>
        <int>10</int>
    </parameter>
</component-implementation>

Aquí necesito pasarle un valor directamente desde la configuración, pero si le paso solamente el parámetro int, Pico no sabe de donde sacar los otros parámetros, y por lo tanto tengo que definirlos explícitamente. La misma configuración en Spring sería:

<bean class=”com.sarcobjects.web.admin.dashboard.QuartzDashboardScheduler”     autowire=”constructor”>
    <constructor-arg index=”3″ value=”6″ />
</bean>

Sólo tengo que incluir el parámetro que Spring no puede deducir. No es que Spring sea mas inteligente, pero la configuración nos permite mezclar parámetros implícitos con explícitos, con el objeto de mantener el tamaño del XML al mínimo. 

Pico soporta diferentes scopes para los beans: application, session y request.
Esto era cierto hace un año, pero ahora Spring 2 también soporta session y request, además del clásico application. Sin embargo, en esta aplicación jamás usamos otros scope que no fuera application.

Pico se integra con Struts y WebWorks, con Hibernate y tiene soporte para AOP.
La integración con Struts esta bien, hasta quizá sea levemente superior a la de Spring. La integración con Hibernate no pasa de soportar un SessionFactory, y la de AOP no tengo idea, quiza si hubiera documentación…
Spring obviamente se integra con estos y muchos mas Frameworks, y de una manera mucho mas completa.

 

En síntesis, Spring puede hacer todo lo que Pico hace. Sin embargo, si hacemos la pregunta al revés, puede hacer Pico todo lo que Spring hace?
Definitivamente, no. Para empezar, la documentación. Nosotros usamos Pico en un nivel aceptable porque teníamos a uno de los autores en el equipo. Pero no veo cómo alguien que quiera usar Pico pueda sacarlo andando razonablemente con la documentación que se ofrece en el sitio. En contraposición, Spring tiene una muy buena documentación, varios libros, y miles de desarrolladores en todo el mundo que nos pueden ayudar.
No voy a enumerar todas las facilidades que además aporta Spring (se pueden encontrar por toda la web) para desarrollar una aplicación, pero por ejemplo, el soporte para demarcación declarativa de transacciones me parece buenísimo. De hecho, la arquitectura impuesta por este arquitecto no permite tener transacciones que abarquen mas de una tabla! O sea que básicamente nuestra aplicación no es transaccional.

En fin, cuándo se debería usar Pico? Quizá en aplicaciones chicas, puntuales, que no necesiten integrarse con demasiados otros frameworks, que necesite ser distribuida a muchos puntos.
Pero en aplicaciones mediana a grandes, transaccionales, con integración a otros frameworks, con acceso a web services, y que pueda escalar., no me cabe duda que Spring es una solución muy recomedable.

En el próximo post voy a contar lo que tuve que hacer para volar Pico e  instalar Spring en la aplicación.

Update 26/11: Olvidé comentar que el SpringIDE para Eclipse, facilita todo aún mas al manejar los archivos .xml de Spring, con el autocompletado de elementos, y nombres de clases. Permite clickear en un bean y abrir la clase respectiva en el editor. Nos avisa si hay una referencia a un bean que no existe, o si falta algun setter o constructor para poder inyectar todas las dependencias. Y como si esto fuera poco, además nos genera un gráfico con el mapa de los beans, aunque claro, esto solo funciona cuando las dependencias estan marcadas explícitamente, y no con autowire (aunque podría, supongo que una próxima versión lo incluira).

| show comment » | « hide comment 1 Comment so far
Leave a comment



Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Name (required)

E-mail (required)

URI

Your Comment