No tengo una solución lista para su problema, y no creo que exista. Solo explicaré la solución que uso y lo que consideraría en su caso.
En mi organización, nuestro enfoque es separar nuestras aplicaciones en un back-end de Grails y un front-end en Flex. La razón es que tenemos muchos componentes Flex listos para usar que tomarían demasiado tiempo para volver a implementarlos utilizando tecnologías web puras, pero este no es mi punto.
La creación de un back-end REST en Grails es rápida, ya que las vistas tienen scaffolded cuando corresponde, los controladores son sencillos y la validación de entrada se simplifica enormemente por las restricciones de dominio.
El inconveniente de esta división es que la definición de objetos de dominio debe duplicarse en el front-end. Puede incluir la validación de objetos en el front-end o no, pero si los omite, influirá en la capacidad de respuesta de la interfaz de usuario (solicitudes al servidor REST en llamadas AJAX para validación en tiempo real para obtener los errores) . Al final, nuestra aplicación es bastante engorrosa porque la modificación de objetos en el back-end implica modificaciones en el front-end. Además, hacemos la validación tanto en el front-end como en el back-end, y este código no se comparte, por lo que debe mantenerse en fase y mantenerse en dos lugares.
Nuestras aplicaciones se dividen de una manera similar a dos aplicaciones Grails completamente distintas que no compartirían código. Una solución que funcionaría en su caso pero que no es lo que está buscando, de seguro.
En su caso, veo dos soluciones viables para la interfaz web:
utilizan el Groovy REST client library a buscar y enviar de vuelta a su dominio de objetos directamente desde el controlador. Si es necesario, agrúpelos en objetos de comando que reflejen los objetos de su dominio, de modo que pueda compartir el código de validación con el back-end.
crea algún tipo de REST GORM que reemplaza Hibernate con consultas a su servicio web REST. Puede ver el GORM for Mongo Plugin como un ejemplo de cómo crear dicho reemplazo GORM.
Me gusta la última idea, sería un plugin público útil. Todavía no existe, desafortunadamente.
ya ha respondido gran parte de su propia pregunta al afirmar que debe tener en cuenta los servicios web y un nivel de presentación :) ¿Está buscando más información sobre la arquitectura o las opciones tecnológicas?Supongo que la presentación se desplegará en una zona desmilitarizada y se separará del nivel de servicios por un cortafuegos ... ¿tiene alguna restricción arquitectónica adicional que influya materialmente en una respuesta? – darrend
Estoy buscando una solución centrada en Grails. Me parece que la semántica ya existe para que la plataforma me ayude. Considere dos extremos: (1) señala un complemento de "bala mágica" que transforma instantáneamente mi controlador, taglib y código de servicio para que sea consciente remotamente, y produce una compilación de servicio web para mis clases de dominio, o (2) usted explique que Grails no es apto para separar la presentación y la persistencia de esta manera. Ninguno de los dos es sensato, por supuesto, pero en el medio, podrías sugerir una forma de aprovechar lo que tengo de una manera que se ajuste al paradigma de Grails con elegancia. –
¿Cuál es la razón detrás del cortafuegos de la base de datos, pero que permite que las operaciones se realicen a través de un servicio web? ¿Esperas una seguridad mejorada? No veo cómo puede mejorar la seguridad. – Antoine