Configuración Xml versus configuración basada en anotaciones [cerrado]

En algunos proyectos grandes en los que he estado trabajando últimamente, parece ser 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.

Mis preguntas son: ¿cuáles son las ventajas de la configuración basada en XML sobre la configuración basada en anotaciones y cuáles son las ventajas de la configuración basada en anotaciones sobre la configuración basada en XML?

Las anotaciones tienen su uso, pero no son la única bala de plata que mata 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, el uso de algún tipo de anotación en el código que necesita las dependencias hace que el código sea consciente de esta configuración automática.

Sin embargo, en lugar de usar XML para la gestión transaccional, marcar un método como transaccional con una anotación tiene mucho sentido, ya que esta es una información que un programador probablemente desearía saber. Pero que una interfaz va a ser inyectada como SubtypeY en lugar de SubtypeX no debe incluirse en la clase, porque si ahora desea inyectar SubtypeX, debe cambiar su código, mientras que de todos modos tenía un contrato de interfaz. con XML, solo necesitaría cambiar las asignaciones de XML y es bastante rápido e indoloro hacerlo.

No he usado anotaciones JPA, por lo que no sé qué tan buenas son, pero diría que dejar el mapeo de beans a la base de datos en XML también es bueno, ya que al objeto no debería importarle de dónde 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), por supuesto, anímate.

En general: si una anotación proporciona funcionalidad y actúa como un comentario en sí mismo, y no vincula el código a algún proceso específico para que funcione normalmente sin esta anotación, entonces busque anotaciones. Por ejemplo, un método transaccional marcado como transaccional no mata 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 exprese mejor como XML, porque aunque eventualmente afectará la forma en que funciona el código, no cambiará la funcionalidad principal del código y, por lo tanto, no pertenece a los archivos fuente.

Aquí hay un problema más amplio, el de los metadatos externalizados frente a los metadatos en línea. Si su modelo de objetos solo persistirá de una manera, los metadatos en línea (es decir, las anotaciones) son 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, entonces la externalización de los metadatos (es decir, descriptores XML) se vuelve más apropiada.

Ninguno de los dos es mejor, por lo que ambos son compatibles, aunque las anotaciones están más de moda. Como resultado, los nuevos marcos de pelo en llamas como JPA tienden a poner más énfasis en ellos. Las API más maduras, como Hibernate nativo, ofrecen ambas, porque se sabe que ninguna es suficiente.

Siempre pienso en las anotaciones como algún tipo de indicador de lo que es capaz una clase o cómo interactúa con los demás.

La configuración de Spring XML por otro lado para mí es solo eso, configuración

Por ejemplo, la información sobre la ip y el puerto de un proxy, definitivamente va a un archivo XML, es la configuración de tiempo de ejecución.

Usar @Autowire, @Elementpara indicar al marco qué hacer con la clase, es un buen uso de las anotaciones.

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

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

He estado usando Spring durante algunos años y la cantidad de XML que se requería definitivamente se estaba volviendo tediosa. Entre los nuevos esquemas XML y el soporte de anotaciones en Spring 2.5, generalmente hago estas cosas:

1. Uso de "escaneo de componentes" para cargar automáticamente clases que usan @Repository, @Service o @Component. Por lo general, le doy un nombre a cada bean y luego los conecto usando @Resource. Me parece que esta tuberí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 muy bien. Todavía lo uso para transacciones también porque poner @Transactional en todo el lugar es una molestia. Puede crear puntos de corte con nombre para métodos en cualquier servicio o repositorio y aplicar rápidamente el consejo.

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 llamado usando "factory-bean" y "factory-method" en referencia al LCEMFB.

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 bean" en Spring forman un nivel adicional de abstracción sobre las clases de implementación. Con XML, los beans se definen y hacen referencia en relación con su nombre de bean. Con anotaciones se hace referencia a ellos por su clase / interfaz. (Aunque el nombre del bean existe, no necesita saberlo)

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

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

Ciertamente, puede adoptar un enfoque mixto, pero eso me parece peligroso si solo porque, potencialmente, podría dificultar que los nuevos desarrolladores en un proyecto descubran dónde se configuran o asignan diferentes objetos.

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

Depende de 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 parlanchinas
• menos: las anotaciones son menos visibles

Depende de usted 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 configuraciones basadas en XML, está bien usar la anotación @Autowire. Se está mezclando, pero esta ayuda tanto a la legibilidad como al mantenimiento)

Hay otro aspecto para comparar, como la refactorización y otros cambios de código. cuando se utiliza XML, se requiere un gran esfuerzo para refactorizar porque debe cuidar todo el contenido XML. Pero es fácil cuando se usan anotaciones.

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

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

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 de Seam que también usa Spring y generalmente lo implemento en diferentes servidores de desarrollo y prueba. Entonces me he separado:

• Configuración específica del servidor (como rutas absolutas a los recursos en el servidor): archivo Spring XML
• Inyectando beans como miembros de otros beans (o reutilizando un valor definido por Spring XML en muchos beans): Anotaciones

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

En el ámbito 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 usar Spring IoC con la opción de configuración basada en Xml.

Si se trata solo de pruebas unitarias, los desarrolladores deben aplicar el patrón de inyección de dependencia en su codificación y aprovechar las ventajas de las herramientas de burla como EasyMock o JMock para evitar las dependencias.

Debe intentar evitar usar el contenedor DI en su contexto incorrecto.

La información de configuración que siempre estará vinculada a un componente 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 lidiar con 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 volver a compilar el código fuente de Java, por lo que cualquier cosa que deba reconfigurarse en tiempo de ejecución no puede usar anotaciones.

Por favor, consulte los siguientes enlaces. Pueden ser útiles también.

1. Anotaciones vs XML, ventajas y desventajas
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Esta es la clásica pregunta de '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 infiernos de XML que la gente suele asociar con el edificio y mantener un enfoque basado en XML. Al final, encuentro que los beneficios de la Configuración (como la creación de utilidades para construir, mantener e implementar el archivo de configuración XML) superan a la Convención a largo plazo.

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

Hay algunos pros y contras de la configuración de anotaciones de mi experiencia:

• Cuando se trata de la configuración de JPA, ya que se realiza una vez y generalmente no se cambia con bastante frecuencia, prefiero seguir con la configuración de anotación. Tal vez exista una preocupación con respecto a la posibilidad de ver una imagen más grande de la configuración; en este caso, uso los 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 también 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 la anotación @Configuration con las interfaces Services and Query y la configuración xml para dataSource y la configuración de Spring como contexto: component-scan base-package = "..."
• Pero la configuración xml tiene en cuenta las anotaciones de 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 amplia de todo el proceso comercial. Y suena engorroso tenerlo implementado con un enfoque de anotaciones.

Prefiero combinar ambos enfoques: las anotaciones de Java y el mínimo esencial de xml que minimizan la configuración infierno.

Para Spring Framework, me gusta la idea de poder usar la anotación @Component y configurar la opción "escaneo de componentes" para que Spring pueda encontrar mis Java Beans para que no tenga que definir todos mis beans en XML, ni en JavaConfig. Por ejemplo, para los Java Beans 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 he alejado de Spring XML DSL para definir beans, y ahora estoy a favor del uso de JavaConfig y Spring Annotations porque obtienes algo de tiempo de compilación para verificar tu configuración y algún soporte de refactorización que no tienes. t obtener con la configuración de Spring XML. Mezclo los dos en ciertos casos raros donde descubrí que JavaConfig / Annotations no puede hacer lo que está disponible usando la configuración XML.

Para Hibernate ORM (aún no he usado JPA), todavía prefiero los archivos de mapeo XML porque las anotaciones en las clases de modelo de dominio violan en cierta medida The Clean Architecture, que es un estilo arquitectónico de capas que he adoptado en los últimos años. La violació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 los POJO del modelo de dominio sean un poco menos ignorantes de la persistencia. 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é", entonces puedo ver que definitivamente hay ventajas (como conveniencia y facilidad de mantenimiento) de usar anotaciones de Hibernate / JPA en clases de modelos de dominio sobre archivos de mapeo XML separados.