java - que - Configuración Xml versus configuración basada en anotación
spring framework 5 tutorial español (16)
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 en línea (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 deseara persistir en el modelo de diferentes maneras, la externalización de los metadatos (es decir, los 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 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.
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é prefieren las personas? ¿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?
Creo que la visibilidad es una gran victoria con un enfoque basado en XML. Me parece 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).
Ciertamente puede tener un enfoque mixto, pero eso me parece peligroso si solo porque, potencialmente, haría que a los nuevos desarrolladores en un proyecto les resulte difícil determinar dónde se configuran o mapean los diferentes objetos.
No lo sé; al final XML Hell no me parece tan malo.
Depende de qué cosa quieras 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
Depende de ti 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. Está mezclando, pero esta ayuda a la legibilidad y al mantenimiento)
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 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 herramientas de burla como EasyMock o JMock para eludir las dependencias.
Debería intentar evitar el uso del contenedor DI en su contexto incorrecto.
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.
Existen algunos pros y contras de la configuración de anotación de mi experiencia:
- Cuando se trata de la configuración de JPA, ya que se realiza una vez y, por lo general, no se cambian con bastante frecuencia, prefiero mantener 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 visión más amplia de la aplicación, pero tal vez sea 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: usar la anotación @Configuration con los servicios y las interfaces de consulta y la configuración xml para dataSource y la configuración de primavera, como el contexto: component-scan base-package = "..."
- Pero la configuración xml bifurca las anotaciones de Java cuando se trata de la configuración del flujo (Spring Web Flow o Lexaden Web Flow), ya que es extremadamente importante ver una imagen más completa de todo el proceso comercial. 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.
Hay 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 anotaciones (o mínimas). http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java
He estado usando Spring por algunos años y la cantidad de XML que se necesitaba definitivamente se estaba volviendo tediosa. Entre los nuevos esquemas XML y el soporte de anotaciones en Spring 2.5 generalmente hago lo siguiente:
Usar "escaneo de componente" para autocargar clases que usan @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.
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.
Utilizo 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.
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.
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 gestión transaccional, marcar un método como transaccional con una anotación tiene mucho 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 utilizado las anotaciones de JPA, así que no sé qué tan buenas son, pero podría argumentar que dejar el mapeo de beans en la base de datos en XML también es bueno, ya que al objeto no le importa 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), de todos modos, ve por ello.
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 funcionar normalmente sin esta anotación, entonces busque 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.
Para Spring Framework me gusta la idea de poder usar la anotación @Component y establecer la opción "component-scan" para que Spring pueda encontrar mis beans Java 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 necesites. 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 he usado JPA), prefiero los archivos de mapeo XML porque las anotaciones en las clases del modelo de dominio hasta cierto punto violan The Clean Architecture, que es un estilo de arquitectura de capas 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é", entonces puedo ver que definitivamente hay ventajas (como la conveniencia y facilidad de mantenimiento) de utilizar anotaciones Hibernate / JPA en clases de modelo de dominio en archivos de mapeo XML separados.
Podría estar equivocado, pero pensé que las Anotaciones (como en @Tag y C # [Atributo] de Java) eran una opción de 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.
Siempre pienso en las anotaciones como algún tipo de indicador de lo que una clase es capaz de hacer, o cómo interactúa con otras.
La configuración Spring XML, por otro lado, 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.
Usando @Autowire , @Element para indicar el marco de trabajo, 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.
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. Entonces me he dividido
- Configuración específica del servidor (como rutas absolutas a los recursos en el servidor): archivo Spring XML
- Inyectar beans como miembros de otros beans (o reutilizar un valor definido de 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 los miembros del equipo que no entienden todo el código pueden realizar algunos cambios en la configuración.
Una parte importante en el uso de un enfoque de solo anotación es que el concepto de "nombre de un frijol" desaparece más o menos (se vuelve insignificante).
Los "nombres de frijol" 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 bean existe, no es necesario que lo sepa)
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.
Yo 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) .