2011-07-13 13 views
6

Estamos construyendo una pequeña aplicación usando diferentes capas arquitectónicas como dominio, interfaz, infraestructura y aplicación. Esto sigue el modelo Onion DDD. Ahora me pregunto si hay algún beneficio al dividir la aplicación en un proyecto maven multimódulo. Por lo que puedo ver ahora parece hacer las cosas más difíciles de lo necesario. Toda la aplicación se implementará como un único archivo WAR en un contenedor de Tomcat.¿Hay algún beneficio en usar Maven Multimodule cuando se trabaja en una aplicación pequeña?

+1

Qué exactamente es más difícil que tener un único módulo? – khmarbaise

+0

La dificultad para usar a consiste en Spring applicationContext.xml en todos los módulos. Supongo que necesito crear un applicationContext.xml para usar en Spring para todos los módulos separados, ¿o me falta algo? – Marco

+1

No debería necesitar múltiples contextos de aplicación. Puede tener varios módulos separados y solo un applicationContext.xml para conectar las dependencias de esos módulos. – Lyle

Respuesta

9

Dividiendo su aplicación tiene sentido para lo siguiente:

  • Cuando una determinada parte del proyecto tiene que tener una nueva funcionalidad o correcciones de errores, sólo tiene que concentrarse en ese módulo y ejecutar sólo las pruebas de que . Compilar una fracción de todo el código y ejecutar solo las pruebas relacionadas acelera su trabajo.

  • Puede reutilizar el código de los módulos en diferentes proyectos. Supongamos que su proyecto contiene un código suficientemente genérico y bien escrito para el envío de correo. Si más adelante tiene otro proyecto que necesita la funcionalidad de envío de correo, puede simplemente reutilizar su módulo existente o construir sobre él (en otro módulo agregándolo como una dependencia).

  • Mantenibilidad más fácil a largo plazo. Quizás ahora parece un pequeño proyecto. En unos pocos meses, las cosas pueden parecer diferentes y luego tendrá que hacer más refactorizaciones para dividir las cosas en unidades lógicas (módulos).

  • Claridad conceptual (como añadido por Adriaan Koster).

Acerca de WAR: Puede tener un módulo de ensamblaje que reúne todo y produce un archivo WAR final de todos los módulos relacionados.

Inicialmente, esto puede parecer más trabajo, pero en el largo plazo, los proyectos modulares son más fáciles de trabajar y mantener. La mayoría de los desarrolladores en serio preferiría este enfoque.

+2

Otro beneficio: impone la claridad conceptual de su arquitectura. –

5

El uso de módulos múltiples lo fuerza a tener una jerarquía de dependencias. Usted tiene un módulo que es independiente y no depende de ningún otro de sus módulos. Tienes otro que solo depende de eso. Puede parecer más difícil que permitir que algo dependa de algo más, pero este enfoque da como resultado un lío de dependencias que es difícil de solucionar más tarde.

Si está tratando de seguir un modelo en capas, le sugiero que coloque cada capa en un módulo diferente. Esto asegurará que no tengas la tentación de romper el modelo.

0

La división de su proyecto en múltiples proyectos de maven es útil si desea reutilizar sus clases en otro proyecto o si sus proyectos se implementan en diferentes configuraciones.

Tal vez pensar en un servicio web - si aloja el servidor, se podría construir un proyecto para sus clases de dominio (modelos) y sus interfaces de punto final que podrían ser utilizados por el servidor y el cliente. El servidor sería otro proyecto que está construido para una GUERRA.

Para desarrollar nuevos clientes, también se puede usar el primer proyecto.

Utilice un proyecto principal para la gestión de dependencias en proyectos comunes (como el registro) y diferentes perfiles y configuraciones de compilación.

0

Por lo que sé, Maven ayuda poco para las dependencias de WAR.Como estás hablando de WAR individual, esto nunca debería ser un problema.

Puede separar las clases de Java en varios submódulos "jar", pero si divide el proyecto WAR en varias WAR más pequeñas, al usar un tipo de empaque "superpuesto" las cosas se complican.

Solo información, uno de nuestros proyectos, contiene demasiadas páginas web, por lo que decidimos dividirlo en varios submódulos WAR, sin embargo, la sesión no se comparte entre los diferentes WAR implementados, y no vamos a usar Kerberos cosas. Por fin, modificamos muchas fuentes de Glassfish, Jetty, MyFaces, etc. para que resolvieran cosas de web.xml dentro de los JAR. Y convirtió todo el proyecto en Facelets 2.0 (para evitar la dependencia de JDK tools.jar y el manejador de recursos personalizados), la única razón es cambiar los submódulos WAR a submódulos JAR y mover todas las aplicaciones/páginas web en recursos de clase. Entonces, la conclusión es que Maven hace un gran trabajo para las dependencias de JAR, pero no WAR ni WAR único.

EDITAR Usted puede poner applicationContext.xml en una de las sub-módulo de base, y la importación de classpath:com/example/applicationContext.xml. Además, Spring 3.0 tiene soportes de anotación, puede hacer que el resorte los escanee automáticamente en lugar de declararlos todos en el xml.

2

Respuesta corta: hoy es pequeña, mañana será más grande y más complicado de mantener, reutilización, extender, integrar con otro sistema, y ​​así sucesivamente

Cuestiones relacionadas