Google Guice frente a PicoContainer para inyección de dependencia

100

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.

austen
fuente
Actualización: es posible que también desee considerar CDI 2.0 - Contextos e inyección de dependencia para Java . Estandarizado en JSR 365 a partir de 2017-04.
Basil Bourque

Respuestas:

115

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

Jamie McCrindle
fuente
1
Lo que aprendí (de otra persona en lugar de usarlo yo mismo) es que PicoContainer es más liviano que Guice. Además, mirando el documento PicoContainer también parece ser más sencillo de usar. Buscará dependencias en los propios constructores y no es necesario especificar qué constructor usar. Solo usa uno a juego.
Kissaki
2
Sí, yo también soy grande en PicoContainer. Es solo una solución de "mantenlo simple", pero que funciona, no puedo evitar ver a Spring como hinchado y desactualizado hoy en día. Guice también es agradable (y tiene un buen respaldo con Google), pero creo que Pico también tiene más funciones / flexibilidad, al ser mayor. ¡Es bueno ver buenas alternativas a la desagradable configuración xml!
Manius
En referencia a la descripción "no ampliamente utilizada" de Pico anterior, es cierto que no es tan popular como las otras, pero considerando que es más pequeña / más simple que otras soluciones, es mucho menos probable que se encuentre con problemas inusuales. Si lo hace, hay una lista de correo agradable y muy receptiva. Además, Pico no es invasivo (a menos que decida usar anotaciones, es una opción), no necesita anotaciones como Guice, lo que significa menos trabajo para conectar el código de inyección. (Sí, soy parcial, pero Pico es así de genial) Sin embargo, Guice es sin duda una buena herramienta DI (mejor que Spring IMO).
Manius
1
Utilizo pico en varios proyectos muy grandes (y de uso intensivo) (cientos de tipos de componentes definidos en cada contenedor), y utilicé la mayoría de sus diversas características, y no podría estar más feliz con él.
jhouse
2
Acabo de hacer una prueba de rendimiento simple con Guice / Spring / PicoContainer: Guice y PicoContainer son bastante similares. En algunos casos, Guice fue un poco más rápido. La primavera fue muy lenta en todos los casos.
Joshua Davis
25

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 ...

Manius
fuente
1
¿Te importaría decir por qué Pico y Guice son superiores a Spring?
Thorbjørn Ravn Andersen
4
Pensé que sí, básicamente, hacen DI igual de bien, son más simples / más pequeños / más limpios, y ninguna o pocas dependencias. Eso no quiere decir que Spring nunca tenga sentido (estoy seguro de que hay casos), todo lo que digo es que cuanto más simple, mejor si se cumplen sus requisitos. Y para una gran cantidad de proyectos, todo lo que necesita son pequeñas bibliotecas de soporte.
Manius
12

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!

Joshua Davis
fuente
Pero el sitio web de Codehaus aún está congelado y no hay información sobre ningún movimiento. Pensé que Pico estaba muerto;)
Vladislav Rastrusny
1
Si el sitio web no está actualizado con el código, puede ser una indicación de que el proyecto ha caído por debajo de la masa crítica.
Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Sí. Desafortunadamente, creo que Pico ha sido reemplazado por Guice y CDI.
Joshua Davis
5
Al 8 de marzo de 2013, el sitio web picocontainer.org parece estar ocupado por un ocupante ilegal de dominios. picocontainer.com parece ser el sitio web canónico ahora.
dOxxx
2

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.

ACAndreani
fuente
Me gusta Dagger, pero parece que todavía no hay un complemento de Gradle en los repositorios públicos para proyectos que no son de Android (es decir, un complemento de Gradle para proyectos de Java "normales"). Lo consideraría para proyectos Java si hubiera un complemento en los repositorios públicos.
Joshua Davis
2

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.

Cellux
fuente
¡Oye, Feather es increíble! Lo he usado para implementar un complemento DI para ActFramework . Hice algunas actualizaciones, por ejemplo, llamo automáticamente a injectFields si es necesario, y soporte al oyente de inyección, avíseme si quiere que le envíe una solicitud de extracción
Gelin Luo
@green Veo que te has mudado a Genie. ¿Podría compartir sus experiencias con el uso de Feather?
BeerBear
1
@beerBear Feather es muy ligero y muy fácil de usar en la mayoría de los casos de uso de DI. Sin embargo, dado que estoy trabajando en un marco MVC de pila completa, necesito una solución que implemente la especificación JSR330 completa. Por eso me mudé a Genie
Gelin Luo
@green Agradezco tu publicación de la explicación para entender mejor.
BeerBear
0

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();
}
Arquímedes Trajano
fuente
2
Si sigue con JSR-330 en su código de biblioteca, puede mantener el código específico del contenedor al mínimo.
Thorbjørn Ravn Andersen
Aún necesita código específico del contenedor en sus pruebas automatizadas. Aunque no significa que tenga un código específico de contenedor en su código real (y no debería de todos modos a menos que planee ejecutar su propio "main", que en una aplicación que escribí para mí mismo lo hice.
Archimedes Trajano