Reutilización de código entre el proyecto Grails - manteniéndolo DRY

Question

El framework Grails tiene muchas construcciones/características que permiten adherirse al principio DRY ("no se repita") dentro de un proyecto. Es decir: dentro de un proyecto específico, rara vez se requiere repetir bloques idénticos de configuración o código. Hasta aquí todo bien.

Sin embargo, cuanto más he trabajado con Grails, más he observado que repito código no dentro del mismo proyecto sino entre proyectos. Es decir, el proyecto A tiene controladores, GSP: e imágenes que se superponen con el proyecto B. Esta es una pesadilla de mantenimiento ya que las correcciones de errores en el proyecto A también se deben corregir en el proyecto B, etc.

Me gustaría tomar DRY al siguiente nivel al no duplicar el código entre mis proyectos.

Mi pregunta: ¿Cómo abordar este problema (violado "inter-proyectos SECO") en sus propios proyectos internos de Grails?

Sea muy específico/concreto. Si es posible, trate de incluir ejemplos de código específicos sobre cómo lo resuelve en la práctica.

Answer 1

Estoy de acuerdo con Lee, el uso de complementos comunes/compartidos es probablemente la mejor manera de hacerlo. En un lugar donde trabajé teníamos bastantes plugins internos por esta misma razón.

El patrón más común es poner sus objetos de dominio común en su propio complemento. Esto funciona muy bien para clases de dominio o servicios. No terminamos refaccionando los controladores, vistas y recursos estáticos en un complemento, pero debería aplicarse el mismo principio.

Relato largo breve: Reutilización de los artefactos de Grails = use un complemento.

Answer 2

Escribir un plugin personalizado es la mejor manera. No es necesario que lo libere en el repositorio público, ya que puede usar un repositorio privado en algún lugar dentro de su propia red.

Todavía no he tenido suficiente código duplicado para sacar un complemento (la mayoría del código repetido en mis proyectos parece estar cubierto por los diversos plugins públicos), pero un complemento puede ser tan simple como unos pocos dominios comunes clases o servicios.

Answer 3

Para agregar a los puntos de Lee y Colin, que son ambos válidos, creo que pensar en términos de múltiples complementos puede producir otros beneficios.

Por ejemplo, puede dividir la funcionalidad de su aplicación en varias piezas y hacer que diferentes personas trabajen en ellas. O puede generar resultados durante la implementación, por ejemplo, si necesita tener dos niveles de acceso a una aplicación: nivel de usuario y administrador: si su modelo de dominio está en un complemento independiente, como sugirió Colin, puede crear fácilmente dos aplicaciones y desplegarlos por separado.

Para mi aplicación, tengo varios complementos específicos para mi proyecto - plugin de clases de dominio, uno que es un montón de código para importar datos (que puedo ejecutar fácilmente en mi sitio), algunos otros complementos para graficar y personalizar andamio. Se necesita pensar un poco más, pero espero que este factoring genere dividendos en el futuro a medida que atraemos más personas al equipo.