que google framework java dependency-injection guice picocontainer

java - google - que es el spring



Google Guice vs. PicoContainer para la Inyección de Dependencia (6)

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

Estamos buscando varias cosas en nuestro marco:

  1. Una pequeña huella de código: lo que quiero decir con una pequeña huella de código 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 el camino, 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 hacer que algo simple funcione? Queremos tener la menor configuración posible.
  4. Tamaño de la comunidad: comunidades más grandes usualmente significa que un proyecto continuará siendo mantenido. No queremos utilizar un marco y tenemos que arreglar nuestros propios errores;) También cualquier pregunta que tengamos en el camino puede (con suerte) ser respondida por la comunidad de desarrolladores / usuarios del framework.

Las comparaciones de los dos marcos con los criterios enumerados serían muy apreciadas. Cualquier experiencia personal que ayude a comparar los dos también sería extremadamente útil.

Descargo de responsabilidad: soy bastante nuevo en la inyección de dependencia, así que disculpe mi noobismo si le hago una pregunta que no es pertinente para esta discusión.

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 intrusismo, 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 contenedor está usando CDI) y el uso de anotaciones (aunque son estándar )

El contenedor ligero de CDI que uso para mis propios proyectos es Apache Open Web Beans. Aunque tardó un tiempo en descubrir cómo crear una aplicación sencilla (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(); }

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, tus clases no necesitan saber acerca de Pico. Solo es el cableado lo que debe saberse (es cierto para todos los marcos DI).

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

Spring - Spring tiene como objetivo permitirle evitar cualquier mención del marco Spring en su código. Debido a que tienen muchos otros ayudantes / utilidades, etc., la tentación es bastante fuerte para 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, ya sea utilizando Guice o el cableado a mano, se debe considerar

Primavera - La primavera puede ser lenta. Ha habido trabajo para hacerlo más rápido y usar la biblioteca JavaConfig debería acelerar las cosas.

Facilidad de uso

Pico - Simple de configurar. Pico puede tomar algunas decisiones automotrices por usted. No está claro cómo se adapta a proyectos muy grandes.

Guice : fácil de configurar, simplemente 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.

Primavera : relativamente fácil de configurar, pero la mayoría de los ejemplos usan Spring XML como método de configuración. Los archivos XML de Spring pueden volverse muy grandes y complejos a lo largo del tiempo y llevar tiempo para cargarlos. Considere usar una mezcla de Spring y Hand Injection Dependency Injection 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 ampliamente 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 proyecto grande 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 ensambla toda nuestra aplicación. Es un poco como AOP en este sentido.

Spring - Spring es generalmente mi elecció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 configuración basada en XML, Spring XML es bastante bueno. Spring también hizo un gran esfuerzo para hacer que otros frameworks sean más amigables con Dependency Injection, lo que puede ser útil porque a menudo usan las mejores prácticas al hacerlo (JMS, ORM, OXM, MVC, etc.).

Referencias

Es una vieja pregunta, pero hoy puede considerar Dagger ( https://github.com/square/dagger ) en su proyecto de aplicación de Android. Dagger genera código en el 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.

La respuesta que arrojó jamie.mccrindle es bastante buena, pero me confunde por qué Spring es la opción predeterminada cuando está bastante claro que hay disponibles alternativas superiores (tanto Pico como Guice). La popularidad de IMO Spring ha llegado a su punto máximo y ahora está viviendo de la emoción generada (junto con todos los otros sub proyectos de primavera "yo también" que buscan viajar en el 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: Significa decir que es extremadamente flexible, no es que tampoco sea 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 enormes archivos jar, con todas sus dependencias. 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 va a hacer que escale mejor? ¿Es este mundo bizarro? No haría suposiciones de que Spring es "más escalable" hasta que eso esté probado (y explicado).

A veces, crear algo bueno (Pico / Guice) y luego mantener las MANOS APAGADAS en lugar de agregar funciones de hinchazón y fregadero con infinitas versiones nuevas realmente funciona ...

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

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

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

  • Pico 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 del contenido anterior.
  • http://picocontainer.codehaus.org/ Lo cual parece congelado en el tiempo en la versión 2.10.2 - Sería realmente agradable si las páginas dijesen algo así como "¡eh, estás viendo un sitio web antiguo!"
  • http://docs.codehaus.org/display/PICO/Home - Una wiki de confluencia que documenta v 1.x, ¡pero no dice eso en ninguna parte de las páginas!

Estoy usando Guice 2.x ahora, a pesar de que es más grande y tiene menos funciones. Era 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á empezando a hincharse, al igual que Spring hizo mucho 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!