Configuración Xml versus configuración basada en la anotación

Question

En algunos proyectos grandes en los que he estado trabajando últimamente, parece cada vez más importante elegir uno u otro (XML o Anotación). A medida que los proyectos crecen, la consistencia es muy importante para la mantenibilidad.

Mi pregunta es, ¿qué es lo que la gente prefiere? ¿Prefiere la basada en XML o la Anotación? ¿o ambos? Todo el mundo habla sobre el infierno de la configuración de XML y cómo las anotaciones son la respuesta, ¿qué pasa con infierno de configuración de anotación?

Answer 1

Las anotaciones tienen su uso, pero no son la única bala para eliminar la configuración XML. ¡Recomiendo mezclar los dos!

Por ejemplo, si usa Spring, es completamente intuitivo usar XML para la porción de inyección de dependencia de su aplicación. Esto aleja las dependencias del código del código que lo usará, por el contrario, al usar algún tipo de anotación en el código que necesita las dependencias, el código toma en cuenta esta configuración automática.

Sin embargo, en lugar de usar XML para la administración de transacciones, marcar un método como transaccional con una anotación tiene perfecto sentido, ya que esta es información que un programador probablemente desearía saber. Pero que una interfaz va a ser inyectada como un SubtypeY en lugar de un SubtypeX no debe ser incluido en la clase, porque si ahora deseas inyectar SubtypeX, tienes que cambiar tu código, mientras que antes tenías un contrato de interfaz, entonces con XML, solo necesitaría cambiar las asignaciones de XML y es bastante rápido y sencillo hacerlo.

No he usado las anotaciones JPA, así que no sé qué tan buenas son, pero yo diría que dejar la asignación de beans a la base de datos en XML también es bueno, ya que al objeto no le debe importar dónde de donde proviene su información, debería importarle lo que puede hacer con su información. Pero si te gusta JPA (no tengo ninguna experiencia con él), de todos modos, ve por ello.

En general: Si una anotación proporciona funcionalidad y actúa como un comentario en sí misma, y ​​no vincula el código a un proceso específico para funcionar normalmente sin esta anotación, entonces vaya por anotaciones. Por ejemplo, un método transaccional marcado como transaccional no anula su lógica operativa y también sirve como un buen comentario a nivel de código. De lo contrario, esta información probablemente se expresa mejor como XML, porque aunque eventualmente afectará la forma en que opera el código, no cambiará la funcionalidad principal del código y, por lo tanto, no pertenece a los archivos fuente.

Answer 2

Podría estar equivocado, pero pensé que las Anotaciones (como en @Tag y C# [Atributo] de Java) eran una opción en tiempo de compilación, y XML era una opción en tiempo de ejecución. Eso para mí dice que no son equivalentes y tienen diferentes pros y contras.

Answer 3

Esta es la clásica pregunta 'Configuración versus Convención'. El gusto personal dicta la respuesta en la mayoría de los casos. Sin embargo, personalmente prefiero la Configuración (es decir, basada en XML) sobre la Convención. Los IDE de IMO son lo suficientemente robustos como para superar algunos de los demonios XML que la gente suele asociar con la construcción y el mantenimiento de un enfoque basado en XML. Al final, creo que los beneficios de la Configuración (como la creación de utilidades para construir, mantener y desplegar el archivo de configuración XML) sobrepasa a la Convención a largo plazo.

Answer 4

Depende de todo lo que desee configurar, porque hay algunas opciones que no se pueden configurar con anotaciones. Si lo vemos desde el lado de las anotaciones:

• más: las anotaciones son menos talky
• menos: las anotaciones son menos visibles

Todo depende de lo que es más importante ...

En general, recomendaría elegir una forma y usarla en alguna parte cerrada del producto ...

(con algunas excepciones: por ejemplo, si elige la configuración basada en XML) iones, está bien utilizar la anotación @Autowire. Se mezcla, pero éste ayuda tanto a la legibilidad y mantenibilidad)

Answer 5

siempre pienso en las anotaciones como una especie de indicador de lo una clase es capaz de hacer, o cómo interactúa con los demás. configuración XML

resorte en el otro lado de mí es sólo eso, configuración

Por ejemplo, la información sobre la dirección IP y el puerto del proxy, va definitivamente en un archivo XML, que es la configuración de ejecución .

Usando @Autowire, @Element para indicar el marco, qué hacer con la clase es un buen uso de las anotaciones.

Poner la URL en la anotación @Webservice es un mal estilo.

Pero esta es solo mi opinión. La línea entre la interacción y la configuración no siempre es clara.

Answer 6

También creo que una mezcla es lo mejor, pero también depende del tipo de parámetros de configuración. Estoy trabajando en un proyecto Seam que también usa Spring y generalmente lo despliego en diferentes servidores de desarrollo y prueba. Así que he dividido:

• configuración específica del servidor (como rutas absolutas a los recursos en el servidor): archivos XML de Spring
• inyectables granos como miembros de otros frijoles (o la reutilización de un valor definido XML primavera en muchos granos): Anotaciones

La diferencia clave es que no tiene que volver a compilar el código para todas las configuraciones cambiantes específicas del servidor, simplemente edite el archivo xml. También existe la ventaja de que los miembros del equipo que no entienden todo el código pueden realizar algunos cambios en la configuración.

Answer 7

Uso ambos. Principalmente XML, pero cuando tengo un montón de beans que heredan de una clase común y tienen propiedades comunes, utilizo anotaciones para esos, en la superclase, por lo que no tengo que establecer las mismas propiedades para cada bean. Como soy un poco fanático del control, utilizo @Resource (name = "referenBean") en lugar de simplemente autocablear cosas (y me ahorro muchos problemas si alguna vez necesito otro bean de la misma clase que el referenBean original) .

Answer 8

Una parte importante en el uso de un enfoque de solo anotación es que el concepto de un "nombre de bean" desaparece más o menos (se vuelve insignificante).

Los "nombres de frijoles" en Spring forman un nivel adicional de abstracción sobre las clases de implementación. Con los beans XML se definen y referencian en relación con su nombre de bean. Con anotaciones, su clase/interfaz hace referencia a ellos.(Aunque el nombre del frijol existe, no es necesario que lo conozca)

Creo firmemente que deshacerse de las abstracciones superfluas simplifica los sistemas y mejora la productividad. Para grandes proyectos, creo que las ganancias al deshacerse de XML pueden ser sustanciales.

Answer 9

He estado usando Spring desde hace unos años y la cantidad de XML que se necesitaba definitivamente se estaba volviendo tediosa. Entre los nuevos esquemas XML y soporte de anotaciones en la primavera de 2,5 que suelo hacer estas cosas:

1. El uso de "componente de exploración" a las clases de carga automática que utilizan @Repository, @Service o @Component. Normalmente le doy a cada judía un nombre y luego los conecto usando @Resource. Encuentro que esta plomería no cambia muy a menudo por lo que las anotaciones tienen sentido.

2. Usando el espacio de nombres "aop" para todos los AOP. Esto realmente funciona genial Todavía lo uso para transacciones porque poner @Transactional por todos lados es como un arrastre. Puede crear puntos de acceso con nombre para los métodos en cualquier servicio o repositorio y aplicar el consejo muy rápidamente.

3. Uso LocalContainerEntityManagerFactoryBean junto con HibernateJpaVendorAdapter para configurar Hibernate. Esto permite que Hibernate descubra automáticamente las clases @Entity en el classpath. Luego creo un bean SessionFactory con el nombre "factory-bean" y "factory-method" que hace referencia al LCEMFB.

Answer 10

Creo que la visibilidad es una gran ventaja con un enfoque basado en XML. Encuentro que el XML no es realmente tan malo, dadas las diversas herramientas que existen para navegar documentos XML (es decir, la ventana de estructura de archivos de Visual Studio + ReSharper).

Sin duda, puede tener un enfoque mixto, pero eso me parece peligroso si solo porque, potencialmente, sería difícil para los nuevos desarrolladores en un proyecto averiguar dónde se configuran o asignan los diferentes objetos.

No lo sé; al final XML Hell no me parece tan malo.

Answer 11

Aquí hay un problema más amplio, el de los metadatos externalizados frente a los inlineados. Si su modelo de objetos solo persistirá de una manera, los metadatos integrados (es decir, las anotaciones) serán más compactos y legibles.

Sin embargo, si su modelo de objetos se reutilizó en diferentes aplicaciones de tal manera que cada aplicación quería persistir en el modelo de diferentes maneras, la externalización de los metadatos (es decir, descriptores XML) se vuelve más apropiada.

Ninguno es mejor, por lo que ambos son compatibles, aunque las anotaciones están más de moda. Como resultado, los nuevos frameworks "hair-on-fire" como JPA tienden a poner más énfasis en ellos. APIs más maduras como Hibernate nativa ofrecen ambas, porque se sabe que ninguna es suficiente.

Answer 12

En el alcance del contenedor DI, considero que la DI basada en anotaciones está abusando del uso de la anotación Java. Al decir eso, no recomiendo usarlo ampliamente en su proyecto. Si su proyecto realmente necesita la potencia del contenedor DI, recomendaría utilizar Spring IoC con la opción de configuración basada en Xml.

Si es solo por una unidad de prueba, los desarrolladores deben aplicar el patrón Dependency Inject en su codificación y aprovechar las ventajas de las herramientas de burla como EasyMock o JMock para eludir las dependencias.

Debe intentar evitar el uso del contenedor DI en su contexto incorrecto.

Answer 13

Existen otros aspectos para comparar, como refactorización y otros cambios de código. cuando se utiliza XML, se requiere un gran esfuerzo para realizar la refactorización, ya que debe ocuparse de todo el contenido XML. Pero es fácil cuando se usan Anotaciones.

Mi forma preferida es la configuración basada en Java sin (o mínima) anotaciones. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Answer 14

Hay algunos pros y los contras de configuración de anotación de mi experiencia:

• Cuando se trata de la configuración de la APP, ya que se hace una vez y por lo general no se cambian muy a menudo prefiero que se adhieren a la configuración de anotación. Puede haber una preocupación con respecto a la posibilidad de ver una imagen más grande de la configuración, en este caso utilizo diagramas MSQLWorkbench.
• La configuración de Xml es muy buena para obtener una imagen más amplia de la aplicación, pero puede ser engorroso encontrar algunos errores hasta el tiempo de ejecución. En este caso, la anotación Spring @Configuration suena como una mejor opción, ya que le permite ver una imagen más grande y también permite validar la configuración en tiempo de compilación.
• En cuanto a la configuración de Spring, prefiero combinar ambos enfoques: use @Configuration anotación con interfaces de servicios y consultas y configuración xml para dataSource y configuración de primavera como contexto: component-scan base-package = "..."
• Pero la configuración xml bits las anotaciones Java cuando se trata de la configuración de flujo (Spring Web Flow o Lexaden Web Flow) ya que es extremadamente importante ver una imagen más grande de todo el proceso de negocio. Y parece engorroso implementarlo con el enfoque de anotaciones.

Prefiero combinar ambos enfoques: anotaciones java y mínimos xml esenciales que minimizan el infierno de la configuración.

Answer 15

La información de configuración que siempre va a estar vinculada a un componente de Java específico (clase, método o campo) es un buen candidato para ser representado por anotaciones. Las anotaciones funcionan especialmente bien en este caso cuando la configuración es esencial para el propósito del código. Debido a las limitaciones en las anotaciones, también es mejor cuando cada componente solo puede tener una configuración. Si necesita manejar múltiples configuraciones, especialmente las que están condicionadas a cualquier cosa fuera de la clase Java que contenga una anotación, las anotaciones pueden crear más problemas de los que resuelven. Finalmente, las anotaciones no se pueden modificar sin recompilar el código fuente de Java, por lo que todo lo que necesite ser reconfigurable en tiempo de ejecución no puede usar anotaciones.

Por favor, consulte los siguientes enlaces. También podrían ser útiles.

1. Annotations vs XML, advantages and disadvantages
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Answer 16

Para Spring Framework me gusta la idea de ser capaz de utilizar la anotación @Component y configurar la opción de "componente de exploración", por lo que la primavera puede encontrar mis Java Beans para que no tenga que definir todos mis beans en XML, ni en JavaConfig. Por ejemplo, para los beans java singleton sin estado que simplemente necesitan conectarse a otras clases (idealmente a través de una interfaz), este enfoque funciona muy bien.En general, para Spring Beans, en su mayor parte, me alejé de Spring XML DSL para definir beans, y ahora estoy a favor del uso de JavaConfig y Spring Annotations porque obtienes algún tiempo de compilación para verificar tu configuración y algún soporte de refactorización que no utilices. Obtener con la configuración Spring XML. Combino los dos en ciertos casos excepcionales en los que he encontrado que JavaConfig/Annotations no puede hacer lo que está disponible utilizando la configuración XML.

Para Hibernate ORM (aún no usé JPA) Todavía prefiero los archivos de asignación XML porque las anotaciones en las clases de modelo de dominio violan en cierto grado The Clean Architecture, que es un estilo de capas de arquitectura que he adoptado en los últimos años. La infracción se produce porque requiere que la capa principal dependa de elementos relacionados con la persistencia, como las bibliotecas Hibernate o JPA, y hace que el modelo de dominio POJO tenga menos persistencia ignorante. De hecho, se supone que Core Layer no depende de ninguna otra infraestructura.

Sin embargo, si The Clean Architecture no es su "taza de té", puedo ver que existen ventajas (como la comodidad y facilidad de mantenimiento) de usar anotaciones de Hibernate/JPA en clases de modelo de dominio en archivos de mapeo XML separados.