Mejores prácticas a seguir durante el desarrollo de la aplicación Grails

Question

Al desarrollar una aplicación Grails, ¿qué considera que son las "mejores prácticas" y por qué? No estoy interesado en un debate sobre las mejores prácticas, pero una o más afirmaciones respaldadas con una justificación y/o una descripción de cuándo se aplican las mejores prácticas y cuándo no. No creo que haya una mejor manera de desarrollar aplicaciones Grails, pero hay una serie de pautas que darán lugar a aplicaciones más sostenibles con menos errores escondidos en ellas.

Mi experiencia de Grails es que ofrece tantas capacidades que existe la tentación de usarlas todas en una sola aplicación, lo que da como resultado uno de los peores códigos de spaghetti que he visto desde que depuré un programa Fortran con GOTO declaraciones dentro y fuera de un ciclo de DO.

Todos sabemos cómo Grails crea un lugar para clases de dominio, servicios, vistas, controladores, etc. ¿Qué tipo de funciones pertenecen a estos lugares? ¿Qué reglas generales te ayudan a hacer lo correcto? ¿Qué son los códigos del código Grails?

Answer 1

1. Comprenda los convenios de Grails. Grails es impulsado por la convención; y las convenciones son cómo Grails puede hacer mucha magia para ti. Las vistas deberían ser vistas. Los controladores solo deberían ser controladores. Los objetos de servicios y modelos deben contener toda la lógica de su aplicación. Esto significa que cuando hace clic en un enlace o invoca un punto final, llama a un Controlador. El controlador invocará un servicio (que a su vez podría invocar otros servicios) y dará una respuesta concisa. El servicio devolverá los objetos o datos del modelo al controlador, lo que simplemente generará una respuesta adecuada. Los servicios son transaccionales, por lo que todo lo que llegue a la base de datos debe ir en un servicio.

2. Prueba. Prueba. Prueba un poco más Tener pruebas es la mejor manera de asegurarse de que pueda agregar funcionalidad sin romper nuevas funcionalidades, es decir, que su proyecto sea mantenible.

3. Dependency Injection. Debe colocar sus componentes en la carpeta grails-app/correspondiente. Los servicios van a la carpeta de servicios. Los controladores van a la carpeta de controladores. Si tiene un objeto modelo Thing y necesita un controlador y servicio para él, su controlador y servicio se deben llamar ThingController y ThingService. Para poner el ThingService en su ThingController, ponga def thingService en su controlador, y grails lo autoconectará. Si no sigue las convenciones de nomenclatura y las reglas sobre dónde colocar los distintos componentes, el autoenvío puede fallar.

4. Comprenda las tecnologías subyacentes, a saber, Spring e Hibernate. Se encontrará con problemas al modelar sus objetos de dominio y hacer que trabajen juntos. Grails es realmente un marco de alta productividad, pero si no entiende cómo funciona Hibernate, se perderá fácilmente cuando intente conseguir que su persistencia se comporte de la manera que desee.

5. Groovy no es Java. Una gran cantidad de conocimiento de Java te servirá bien. Pero Groovy es un lenguaje dinámico y Grails tiene su propio conjunto de errores que se derivan de Groovy. Se encontrará con problemas de tiempo de ejecución al escribir en Grails que evita en gran medida con Java. Las pruebas ayudan con esto.

Estas cosas parecen obvias, pero surgen muchas preguntas sobre estos temas.

Answer 2

Lo que se me ocurre ...

1. prueba lo más que puede con las pruebas unitarias, no pruebas de integración. Las pruebas unitarias son formas más rápidas de ejecutar/depurar y reforzar mejor el acoplamiento bajo.Use mockDomain(), mockLogging() etc.
2. Use grails console para probar y explorar su código en libertad. Incruste una consola Groovy en su interfaz de usuario web; es una herramienta invaluable para examinar el interior de una aplicación en ejecución.
3. Utilice objetos de dominio para modelar la lógica de dominio. Mover la lógica de dominio a Servicios es una resaca de capas de persistencia inconvenientes.
4. Mantenga los controladores breves. Si una lógica se puede expresar en términos de una clase específica, mueva la lógica allí o cree una nueva clase. Pruébalo después.
5. Separar capas. Mantenga la lógica del dominio en las clases de dominio. Mantenga la lógica de presentación en controladores/vistas.
6. transactional El servicio no es la única forma de realizar una transacción. Invocar DomainClass.withTransaction{ ...a couple of lines here... } desde Controller es bastante bueno, siempre y cuando obedezcan al # 4.
7. Esforzarse por la perfección, a diferencia de Java, es posible: D Conoce la tecnología. Utilice Builders, complementos adecuados, Commands, metaprogramación, lo que sea, para hacer que su código sea más corto, más legible, más groovier.

Answer 3

1. evitar la tentación de poner un montón de lógica en la capa web. Para las vistas, esforzarse por hacerlas tan simples como posible. Coloque todos los modelos en sus diseños. Evite la lógica condicional como la peste. Dividir contenido compartido en plantillas y g:render ellos. Crea tu propio taglib para elementos comunes de UI.

2. De manera similar, mantenga sus controladores tan simples como sea posible. Los desarrolladores inexpertos parecen tener el hábito de tirar todo en el controlador, porque parece más obvio. Algunas sugerencias: las consultas y la lógica de recuperación de objetos pueden ir en objetos de dominio. Si ve withTransaction() y necesita un comportamiento transaccional, es un buen candidato para un servicio. Si tiene un enlace de datos complejo, divídalo en un objeto de comando.

3. Para objetos de dominio, aproveche la posibilidad de anular setters y getters para facilitar el trabajo de las propiedades. Crear consultas cortas con nombre y encadenarlas juntas es una forma excelente de descomponer la lógica de consulta compleja. Todo lo que se aplica a un único objeto de ese tipo con pocas dependencias debe ir en la clase de objeto de dominio. Sin embargo, mantenga la lógica específica para ese objeto. La lógica empresarial más compleja que trata con grupos de objetos pertenece a los servicios.

4. En caso de duda, puede ir en un servicio. Los servicios deben ser apátridas. Si encuentra que necesita almacenar estado, probablemente necesite un nuevo objeto de dominio.

Answer 4

1. Desarrollar reutilizables partes de su aplicación como Grails plugins. Estos complementos se pueden probar de forma individual y eliminarán la complejidad de su (s) aplicación (es) principal (es). Considere publicar los complementos en el repositorio de plugins públicos si cree que otros pueden beneficiarse de ellos.

2. Use la liberación (anteriormente conocido como experto-editor) plugin para implementar plugins internos para su repositorio Maven.

3. Familiarícese con el recurso complemento para el manejo de recursos estáticos. Este complemento formará parte de Grails 1.4 y será utilizado por muchos plugins populares.

4. No tenga miedo de buscar en el código fuente de los complementos de terceros que está utilizando o Grails sí mismo para ese asunto (esto me ha ahorrado tantas veces!). Grails y muchos de los complementos más populares alojan su código fuente en GitHub, lo que lo hace muy conveniente para navegar por el código, proyectos fork y contribuir parches.