¿Por qué no hay ningún archivo de configuración para la inyección de dependencia con Google Guice?

Question

Estoy revisando Google Guice as DI framework pero estoy un poco desconcertado: ¿por qué no hay ningún archivo de configuración?

Encontré una explicación parcial en this question pero todavía no está claro cómo podría establecer mis roles de componentes (o cualquier otra cosa que necesite usar un conmutador) sin un archivo de configuración.

Cualquier ayuda apreciada!

Answer 1

La configuración está en el código en lugar de archivos de configuración, que es una decisión válida para muchos escenarios.

Sí, significa que debe reconstruir (posiblemente solo los módulos) si desea liberar una forma diferente de conectar la aplicación, aunque por supuesto todavía podría obtener algunos valores de configuración de argumentos de línea de comandos, archivos de propiedades etc. si quieres.

Si regularmente necesita cambiar la plomería de su aplicación y no desea volver a desplegar nada más que un único archivo, Guice puede no ser para usted. Si, por otro lado, su principal razón para usar DI es hacer que su código sea más claro, y en producción siempre usará la misma fontanería (o lo suficientemente cerca), entonces Guice es una buena opción; a menudo hay bits de lógica que desea para usar al ordenar la tubería de todos modos, y los componentes que generalmente son difíciles de describir/construir de forma declarativa.

Diferentes marcos de DI tienen diferentes beneficios y compensaciones: use el que sea más adecuado para su aplicación.

Answer 2

Mucha configuración en Guice es implícita, a través de @Inject Annotation. Una gran complejidad en los proyectos proviene de una gran cantidad de artefactos del proyecto. Archivos Java, archivos Xml, archivos de propiedades, bases de datos, parámetros ... Guice intenta eliminar una parte de esta complejidad al no usar archivos de configuración.

El reencadenamiento de su aplicación es sencillo en tiempo de compilación. Lo más probable es que solo necesite editar su clase de módulo. Para la mayoría de las clases administradas por Guice, no necesitarás ninguna configuración, solo @Inject en los lugares correctos; solo necesitarás configurar nada cuando tengas dos implementaciones diferentes de la misma interfaz o cuando quieras inyectar clases desde bibliotecas externas que usan clases de Proveedor.

Answer 3

La mayor parte de la configuración DI será la misma de una implementación a otra, por lo que pueden configurarse usando código, lo que hace que la configuración de Guice sea muy concisa y obtenga los beneficios de la verificación del tipo de compilación, herramientas de refactorización, código navegación, etc.

Para las pocas cosas que cambian de una implementación a otra, como la configuración de nombre de usuario y contraseña de la base de datos, puede escribir el código necesario usted mismo. Escriba un código que lea el archivo de configuración (quizás un archivo de propiedades), analice los parámetros y los vincule en sus módulos de Guice para que su aplicación tenga acceso a ellos. El código que se necesita para hacer eso no tomará muchas líneas de código.

Answer 4

No estoy seguro de lo que quiere decir con el archivo, pero Guice le permite cambiar las implementaciones a través de Binder y Providers personalizado.

Answer 5

Es trivial introducir boostrapping usando archivos de configuración si así lo desea. Usamos Guice junto con una API simple que carga archivos de propiedades donde van las cosas que realmente necesitan ser parametrizadas. Esto se puede usar junto con las anotaciones @Named y demás, y por supuesto puede tener algunos condicionales en los módulos (aunque es una buena idea no sobrepasar eso).

Este es un ejemplo de cómo parte de nuestro programa previo se estableció:

public class MetModules extends AbstractModule { 

    private static final Logger log = LoggerFactory.getLogger(MetModules.class); 

    private final Settings settings; 

    public MetModules(Settings settings) { 
     this.settings = settings; 
    } 

    @Override 
    protected void configure() { 

     // common (stage independent modules) go here 
     install(new CommandsModule()); 
     install(new ServletsModule()); 
     install(new DataBaseModule(settings)); 
     install(new JobsModule(settings)); 

     // any development/ production specific modules 
     Stage stage = currentStage(); 
     if (Stage.DEVELOPMENT.equals(stage)) { 
      configureForDevelopment(); 
     } else { // PRODUCTION 
      configureForProduction(); 
     } 
    } 

    /** 
    * Install modules that will be used in development. 
    */ 
    private void configureForDevelopment() { 

     // Mock implementation of email delivery that just logs it got a 
     // message rather than trying to send it. 
     install(new AbstractModule() { 
      @Override 
      protected void configure() { 
       bind(Delivery.class).toInstance(new Delivery() { 

        public String deliver(MailMessageExchange exchange) 
          throws DeliveryException { 
         log.info("email message: " 
           + exchange.getMessage().getMailMessage() 
           + " to " 
           + Arrays.asList(exchange.getMessage() 
             .getMailMessage().getTo()) 
           + " (not sent)"); 
         return "fooMessageId"; 
        } 
       }); 
      } 
     }); 

     // local in-memory registry suffices 
     install(new LocalServiceRegistryModule()); 

     // local in memory db implementations of services 
     install(new LocalServicesModule()); 
    } 

    /** 
    * Install modules that will be used in production. 
    */ 
    private void configureForProduction() { 
     // we really only need this (error interception and audit logging) 
     // in production 
     install(new AopModule()); 
     install(new ZooKeeperServiceRegistryModule());  } 
} 

Dónde configuración es lo que lee nuestros archivos de propiedades y tal. En este momento, el desarrollo/producción, junto con ajustes específicos específicos para las implementaciones, parece hacer el trabajo por nosotros, pero podríamos ir más allá si lo quisiéramos, obviamente.

Answer 6

Recientemente he creado el siguiente proyecto.

http://code.google.com/p/guice-property-injector/

Es WIP, pero permite la inyección de tiempo de ejecución de las propiedades de un archivo de propiedades basado en el medio ambiente.