Google Guice frente a PicoContainer para inyección de dependencia

Mi equipo está investigando marcos de inyección de dependencia y está tratando de decidir entre usar Google-Guice y PicoContainer.

Buscamos varias cosas en nuestro marco:

1. Una huella de código pequeña: lo que quiero decir con una huella de código pequeña es que no queremos tener basura de código de inyección de dependencia en todas partes en nuestra base de código. Si necesitamos refactorizar en el futuro, queremos que sea lo más fácil posible.
2. Rendimiento: ¿cuánta sobrecarga tiene cada marco al crear e inyectar objetos?
3. Facilidad de uso: ¿hay una gran curva de aprendizaje? ¿Tenemos que escribir montones de código para que algo simple funcione? Queremos tener la menor configuración posible.
4. Tamaño de la comunidad: las comunidades más grandes generalmente significan que se seguirá manteniendo un proyecto. No queremos usar un marco y tenemos que corregir nuestros propios errores;) Además, cualquier pregunta que tengamos en el camino puede (con suerte) ser respondida por la comunidad de desarrolladores / usuarios del marco.

Se agradecería enormemente la comparación de los dos marcos con los criterios enumerados. Cualquier experiencia personal que ayude a comparar los dos también sería de gran ayuda.

Descargo de responsabilidad: soy bastante nuevo en la inyección de dependencias, así que disculpe mi novicia si hice una pregunta que no sea pertinente para esta discusión.

Es posible que desee incluir Spring en su lista de marcos de inyección de dependencia que está considerando. Aquí hay algunas respuestas a sus preguntas:

Acoplamiento al marco

Pico : Pico tiende a desalentar la inyección de setter, pero aparte de eso, sus clases no necesitan saber sobre Pico. Es solo el cableado lo que necesita saber (cierto para todos los marcos DI).

Guice - Guice ahora admite las anotaciones JSR 330 estándar , por lo que ya no necesita anotaciones específicas de Guice en su código. Spring también admite estas anotaciones estándar. El argumento que usan los chicos de Guice es que sin un procesador de anotaciones Guice en ejecución, estos no deberían tener un impacto si decide usar un marco diferente.

Spring : Spring tiene como objetivo permitirle evitar cualquier mención del marco Spring en su código. Sin embargo, debido a que tienen muchos otros ayudantes / utilidades, etc., la tentación es bastante fuerte de depender del código Spring.

Actuación

Pico : no estoy muy familiarizado con las características de velocidad de Pico

Guice - Guice fue diseñado para ser rápido y la comparación mencionada en la referencia tiene algunos números. Ciertamente, si la velocidad es una consideración principal, se debe considerar el uso de Guice o el cableado a mano.

Primavera : la primavera puede ser lenta. Se ha trabajado para hacerlo más rápido y el uso de la biblioteca JavaConfig debería acelerar las cosas.

Facilidad de uso

Pico : fácil de configurar. Pico puede tomar algunas decisiones sobre el cableado automático por usted. No está claro cómo se adapta a proyectos muy grandes.

Guice : fácil de configurar, solo agrega anotaciones y hereda de AbstractModule para unir las cosas. Se adapta bien a proyectos grandes ya que la configuración se mantiene al mínimo.

Spring : relativamente fácil de configurar, pero la mayoría de los ejemplos usan Spring XML como método de configuración. Los archivos Spring XML pueden volverse muy grandes y complejos con el tiempo y tardar en cargarse. Considere usar una mezcla de Spring y Dependency Injection con manivela para superar esto.

Tamaño de la comunidad

Pico - Pequeño

Guice - Medio

Primavera - Grande

Experiencia

Pico : no he tenido mucha experiencia con Pico, pero no es un marco muy utilizado, por lo que será más difícil encontrar recursos.

Guice : Guice es un marco popular y su enfoque en la velocidad es bienvenido cuando tienes un gran proyecto que estás reiniciando mucho en desarrollo. Me preocupa la naturaleza distribuida de la configuración, es decir, no es fácil ver cómo se arma toda nuestra aplicación. Es un poco como AOP a este respecto.

Primavera : la primavera suele ser mi opción predeterminada. Dicho esto, el XML puede volverse engorroso y la desaceleración resultante molesta. A menudo termino usando una combinación de Dependency Injection y Spring hechos a mano. Cuando realmente necesita una configuración basada en XML, Spring XML es bastante bueno. Spring también hizo un gran esfuerzo para hacer que otros marcos fueran más amigables con la inyección de dependencias, lo que puede ser útil porque a menudo usan las mejores prácticas al hacerlo (JMS, ORM, OXM, MVC, etc.).

Referencias

• Pico
• Guice
• Primavera
• Comparación Spring / Guice / Pico
• Otra comparación de rendimiento de Spring / Guice

La respuesta de jamie.mccrindle es bastante buena, pero me confunde por qué Spring es la opción predeterminada cuando está bastante claro que hay alternativas superiores disponibles (tanto Pico como Guice). La popularidad de IMO Spring ha alcanzado su punto máximo y ahora vive de la exageración generada (junto con todos los otros subproyectos de Spring "yo también" que buscan subirse al tren de Spring).

La única ventaja real de Spring es el tamaño de la comunidad (y, francamente, debido al tamaño y la complejidad, es necesario), pero Pico y Guice no necesitan una gran comunidad porque su solución es mucho más limpia, más organizada y más elegante. Pico parece más flexible que Guice (puede usar anotaciones en Pico o no, es extremadamente eficiente). (Editar: quiero decir que es extremadamente flexible, no que no sea también eficiente).

El pequeño tamaño de Pico y la falta de dependencias es una GRAN victoria que no debe subestimarse. ¿Cuántos megas necesitas descargar para usar Spring ahora? Es un lío de archivos jar enormes, con todas sus dependencias. Pensándolo de manera intuitiva, una solución tan eficiente y "pequeña" debería escalar y funcionar mejor que algo como Spring. ¿La hinchazón de Spring realmente hará que escale mejor? ¿Es este mundo bizarro? No haría suposiciones de que Spring es "más escalable" hasta que se pruebe (y se explique).

A veces, crear algo bueno (Pico / Guice) y luego mantener las MANOS FUERA de él en lugar de agregar funciones de hinchazón y fregadero de cocina con un sinfín de nuevas versiones realmente funciona ...

NOTA: Esto es más un comentario / perorata que una respuesta.

PicoContainer es genial. Volvería a usarlo si simplemente arreglaran sus sitios web. Es realmente confuso ahora:

• http://picocontainer.com, que es el más reciente, pero muchas páginas tienen problemas de formato y algunas páginas no funcionan en absoluto. Parece que las páginas se convirtieron automáticamente a partir del contenido anterior.
• http://picocontainer.codehaus.org/ Que parece congelado en el tiempo en la versión 2.10.2 - Sería muy bueno si las páginas dijeran algo como "¡Oye, estás viendo un sitio web antiguo!"
• http://docs.codehaus.org/display/PICO/Home - Un wiki de confluencia que documenta la versión 1.x, ¡pero no dice eso en ninguna parte de las páginas!

Estoy usando Guice 2.x ahora, aunque es más grande y tiene menos funciones. Fue mucho más fácil encontrar la documentación y su grupo de usuarios es muy activo. Sin embargo, si la dirección de Guice 3 es una indicación, parece que Guice está comenzando a hincharse, al igual que Spring lo hizo en los primeros días.

Actualización: publiqué un comentario a la gente de Pico Container y han realizado algunas mejoras en el sitio web. ¡Mucho mejor ahora!

Es una pregunta antigua, pero hoy puede considerar Dagger ( https://github.com/square/dagger ) en su proyecto de aplicación de Android. Dagger genera código en tiempo de compilación. Por lo tanto, obtiene un tiempo de inicio más corto y menos uso de memoria en el tiempo de ejecución.

Si buscas un contenedor DI minimalista, puedes echarle un vistazo a Feather . Funcionalidad Vanilla JSR-330 DI solamente, pero bastante buena en términos de espacio (16K, sin dependencias) y rendimiento. Funciona en Android.

Aunque me gusta PicoContainer por su simplicidad y su falta de dependencias. En su lugar, recomendaría usar CDI porque es parte del estándar Java EE, por lo que no tiene un bloqueo de proveedor.

En términos de intrusión, su principal problema es el requisito de un contenedor y el uso de un archivo META-INF / beans.xml relativamente vacío (necesario para indicar que el jar está usando CDI) y el uso de anotaciones (aunque son estándar )

El contenedor CDI ligero que utilizo para mis propios proyectos es Apache Open Web Beans. Aunque tomó un tiempo descubrir cómo crear una aplicación simple (a diferencia de Pico) que se ve así.

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}