XML parece ser el lenguaje del día, pero no es de tipo seguro (sin una herramienta externa para detectar problemas) y terminas haciendo lógica en XML. ¿Por qué no solo hacerlo en el mismo idioma que el resto del proyecto? Si es Java, puedes construir un jar de configuración y ponerlo en el classpath.¿Qué hay de malo en hacer la configuración de Inyección de Dependencia en el código?
Me falta algo profundo.
La desventaja principal de la configuración DI en el código es que fuerza una recompilación para cambiar su configuración. Al usar archivos externos, la reconfiguración se convierte en un cambio de tiempo de ejecución. Los archivos XML también proporcionan una separación adicional entre su código y configuración, lo que mucha gente valora mucho.
Esto puede facilitar las pruebas, el mantenimiento, la actualización en sistemas remotos, etc. Sin embargo, con muchos idiomas, puede usar la carga dinámica del código en cuestión y evitar algunas desventajas, en cuyo caso las ventajas disminuyen .
Me parece que un argumento de cop out. El 99% del tiempo, si desea cambiar su configuración de DI, es un cambio lo suficientemente profundo como para necesitar una recompilación de todos modos. y siempre que empaque sus clases de configuración por separado, hay muy poca diferencia entre editar un archivo xml y reemplazar config-test con config-production. Los beneficios, por otro lado, se refieren a un lenguaje que en realidad es legible, y uno con el que tenemos muchísimas herramientas altamente evolucionadas para trabajar. –
(no significa que sea tan "agresivo" como eso sonó, lo voté porque es por eso que se usa xml para esto. Realmente no estoy de acuerdo con la opinión) –
Je, yo no necesariamente siempre estoy de acuerdo con eso tampoco. En mi proyecto actual, hacemos mucha configuración DI (más configuración ORM) en código vs. en XML, porque tiene sentido para nosotros. Sin embargo, este es un argumento frecuentemente promocionado, y tiene su lugar, y es por eso que lo menciono. Personalmente, prefiero la configuración en el código ya que obtiene el tiempo de compilación en lugar de tener que depender de las comprobaciones en tiempo de ejecución de sus archivos de configuración, pero eso es una preferencia personal y no una respuesta directa a la pregunta. –
No hay nada intrínsecamente incorrecto al hacer la configuración en el código, es solo que la tendencia es usar XML para proporcionar cierta separación.
Existe la creencia generalizada de que, de alguna manera, tener su configuración en XML lo protege de tener que reconstruir después de un cambio. La realidad en mi experiencia es que necesita volver a empaquetar y volver a implementar la aplicación para entregar los archivos XML modificados (en el caso del desarrollo web de todos modos), por lo que podría cambiar también algunos archivos de "configuración" de Java. Yo podría simplemente soltar los archivos XML en el servidor web y actualizar, pero en el entorno en el que trabajo, la auditoría tendría un ajuste si lo hiciéramos.
Lo principal que se logra con la configuración de XML en mi opinión es forzar a los desarrolladores a pensar en la inyección de dependencia y en la separación de las preocupaciones. en Spring (entre otros), también proporciona un gancho conveniente para colgar sus proxies AOP y cosas por el estilo. Ambos pueden lograrse en la configuración de Java, es menos obvio dónde se dibujan las líneas y la tendencia puede ser reintroducir las dependencias directas y el código de spaghetti.
Para obtener información, hay un Spring project que le permite realizar la configuración en el código.
El proyecto de configuración Spring Java (JavaConfig para abreviar) proporciona una opción de Java pura segura para la configuración del contenedor Spring IoC. Si bien XML es un enfoque de configuración ampliamente utilizado, la versatilidad de Spring y el manejo interno basado en metadatos de las definiciones de beans significa que las alternativas a la configuración de XML son fáciles de implementar.
Muchas gracias por el enlace de Spring Project. Estaba completamente inconsciente. –
De nada, aunque vale la pena señalar que aún no está en la versión 1.0 –
XML no tiene lógica, y está lejos de ser un lenguaje de programación.
XML se utiliza para almacenar los datos de una manera fácil de entender y modificar.
Has dicho que a menudo se usa para almacenar definiciones, no lógica de negocios.
De acuerdo, que debería ser así, pero en primavera hace mucho más que eso. Es bastante posible inyectar los beans de forma condicional, por lo que la lógica está en el archivo XML. –
Martin Fowler cubierto esta decisión bastante bien aquí:
http://martinfowler.com/articles/injection.html
Evitar la tentación de plagiar ... simplemente ve a leer la sección "Archivos de código o configuración".
Es malo porque hace las pruebas más difíciles.
Si está escribiendo código y usa métodos como getApplicationContext() para obtener las dependencias, está descartando algunos de los beneficios de la inyección de dependencia.
Cuando sus objetos y servicios no necesitan saber cómo crear o adquirir los recursos de los que dependen, están más débilmente asociados a esas dependencias.
El acoplamiento flojo significa una prueba más fácil de la unidad. Es difícil conseguir algo en un junit si necesita crear una instancia de todas sus dependencias. Cuando una clase omite suposiciones acerca de sus dependencias, es fácil usar los objetos simulados en lugar de los reales con el propósito de probar.
Además, si puede resistir la tentación de usar getApplicationContext() y otras técnicas de DI basadas en código, entonces (a veces) puede confiar en autovío de resorte lo que significa que significa aún menos trabajo de configuración. La configuración funciona ya sea en código o en XML es tedioso, ¿verdad?
Si así es como lo implementarías, entonces no estás haciendo una inyección de dependencia. Incluso si usa xml para la configuración, aún necesita construir su Bean Factory. –
De hecho, estoy argumentando en contra de usar getApplicationContext(). – nont
Mencionó Spring en un comentario a su pregunta, por lo que sugiere que le pueda interesar el hecho de que Spring 3 le permite express your application contexts in Java rather XML.
Es un poco emocionante, pero la definición de sus beans, y sus interdependencias, se puede hacer en Java. Todavía mantiene una separación limpia entre la configuración y la lógica, pero la línea se vuelve un poco más borrosa.
XML es principalmente un formato de datos (sustantivo). El código es principalmente un formato de procesamiento (verbo). Desde el punto de vista del diseño, tiene sentido tener su configuración en XML si es principalmente sustantivos (direcciones, valores, etc.) y codificar si se trata principalmente de verbos (indicadores de procesamiento, configuraciones de manejador, etc.).
En mi experiencia, la estrecha comunicación entre el equipo de desarrollo y el equipo de infraestructura se puede fomentar lanzando con frecuencia. Mientras más liberes, más sabes realmente cuál es la variabilidad entre tus entornos. Esto también le permite eliminar configuraciones innecesarias.
Aquí se aplica un corolario a la ley de conway: sus archivos de configuración se parecerán a la variedad de entornos en los que se implementa su aplicación (planificada o real). Cuando tengo un equipo que despliega aplicaciones internas, tiendo a conducir hacia config en código para todos los problemas arquitectónicos (pools de conexión, etc.) y config en archivos para todas las configuraciones ambientales (nombres de usuario, cadenas de conexión, direcciones IP). Si hay diferentes inquietudes arquitectónicas en diferentes entornos, los encapsularé en una sola clase y convertiré ese nombre de clase en parte de los archivos de configuración, p.
container.config = FastInMemoryConfigurationForTesting container.config = ProductionSizedConfiguration
Cada uno de estos va a utilizar una configuración común, pero anulará/reemplazar aquellas partes de la arquitectura que deba sustituirse.
Sin embargo, esto no siempre es apropiado. Hay varias cosas que afectarán su elección:
1) cuánto tarda después de liberar una nueva gota antes de desplegarse con éxito en cada entorno de producción y recibe comentarios sobre ese entorno (tiempo de ciclo) 2) La variabilidad en entornos implementados 3) La precisión de los comentarios obtenidos de los entornos de producción.
Por lo tanto, cuando tiene un cliente que distribuye su aplicación a sus equipos de desarrollo para la implementación, tendrá que hacer que su aplicación sea mucho más configurable que si la implementara usted mismo. Usted podría seguir confiando en la configuración en el código, pero eso requiere que el público objetivo entienda su código. Si utiliza un enfoque de configuración común (por ejemplo, Spring), le facilitará a los usuarios finales la adaptación y los problemas de solución en su producción.
Pero una rúbrica es: la capacidad de configuración es un sustituto de la comunicación.
¿Qué quiere decir con "configuración"? –
Encontré lo que se estaba perdiendo: cumplimiento de palabra de moda. ;-) –
En primavera, la configuración sería el cableado de frijoles usualmente hecho a través del archivo XML applicationContext.xml –