Duda básica sobre MVC Controles y Servicios.

[Alejandro Torres Brito]

Hola a todos, soy nuevo en Grails, vamos soy nuevo en frameworks no llego a entender la diferencia entre Controladores y Servicios, Creo haber entendido que Servicio se usa para los casos de uso. Saben de algún artículo o ejemplo donde venga claro? Saludos y gracias por adelantado. :)

[Rafael Bermúdez Míguez]

Hola Alex,

 

en un MVC la diferencia básica es que el servicio encapsula la lógica de negocio de la aplicación (se rige por el patrón Facade) , mientras que el controlador lleva la lógica de manejo de la vista (leer parámetros, llamar a los servicios necesarios y redirigir/rellenar la vista correspondiente)  .

 

Por ejemplo, tenemos una pequeña app web que calcula el máximo común divisor de 2 nºs

 

-tenemos una vista formularioEntrada que recibe 2 parámetro:  2  números naturales,

 

- el action del controlador de ese submit haría:

recoge los parámetros

rellena una variable llamando a una funcion "calculaMaximoComunDivisor" del servicio que nos calcula el máximo común divisor de esos 2 números

procesa la llamada a la vista de resultado con esa variable

 

- la función "calculaMaximoComunDivisor" de ese servicio en este caso recibiría 2 enteros, realizaría los cálculos pertinentes , y devolvería otro entero.

 

Como ves, desde el controlador no se conocen los detalles de implementación de la función. Y la función conoce dónde es utilizada . Esto puede suponer grandes ventajas:

 

Los action del controlador quedan más limpios. se dedican a recoger la entrada, invocar, preparar la salida.

Las funciones del servicio quedan mucho más límpias, sin operaciones de recogida/ relleno de parámetros por el medio.

Si necesito utilizar la función en varios puntos, las ventajas son evidentes

Puedo tener un equipo que programe la capa modelo, y otro la vista/controlador.

Al separar el modelo de la vista: puedo testearlo independientemente, puedo utilizarlo en múltiples vistas, etc.

Si encuentro una forma más óptima de realizar el calculaMaximoComunDivisor, puedo modificarlo siempre que se respete la firma.

...etc

 

 

 

 

 

Si encontramos una forma más óptima de hacer 

[Rafael Bermúdez Míguez]

Otro ejemplo:

 

imagina que hacemos un criteria desde un action de un controlador, que nos busca en BD todos los usuarios con los roles "PROGRAMADOR" o "ANALISTA". Este criteria lo utilizamos para rellenar combos en múltiples vistas, por lo que se escribe en múltiples actions ( programación orientada a copy&paste)

 

¿Cómo podemos testear esa lógica (test automáticos)? ¿En todos y cada uno de los controladores? No es una buena práctica ( ni eficiente, es mucho más razonable disponer de tiempo para testear el modelo que para los controladores)

 

Ahora bien, imagina que añadimos el rol "ANALISTA-PROGRAMADOR" y queremos que aparezcan esos usuarios también en el combo. ¿Tenemos que ir buscando por todos los controladores ese criteria para cambiarlo?

 

Busca cualquier libro que hable sobre el modelo MVC y el patron facade, y te quedará todo más claro.

 

PD: otra discusión sería si en estos frameworks modernos como grails y su gorm es lógico utilizar MVC 100% puro

 

Un saludo! :)

 

 

El jueves, 7 de noviembre de 2013 12:54:00 UTC+1, Alejandro Torres Brito escribió:

[Alejandro Torres Brito]

Muchas gracias Rafa he tenido que desempolvar los apuntes de ingeniería del software orientado a objetos, he visto que el más común es usando una clase fachada nueva pero hay otra forma que es de la clase creada B que sólo tenga una entrada, para grails es más recomendada la primera? Saludos. Ya lo he entendido gracias por la explicación.

[Rafael Bermúdez Míguez]

Buenas Alejandro,

antes de nada decirte que la arquitectura depende de la aplicación que quieras desarrollar. Pero para la mayoría de los casos podría decirse:

Buenas prácticas: hql, gorm, criterias y sql en servicios, no en controladores.
seguramente no necesites aplicar un patrón facade puro. Quédate con el concepto. 

En este caso un servicio se diseña como una fachada entre los controladores y las consultas/lógica_de_negocio. No es necesario crear una clase fachada que agrupe varios servicios. Nosotros para la mayoría de las aplicaciones grails,  prescindimos de una arquitectura compleja con fachadas o capas dao puras, y en los servicios utilizamos hql, gorm, criterias, etc.

Es decir, buscamos sencillez y tenemos "sólo" controladores -> servicios (servicios realizan las consultas, cada servicio es como una fachada de lógica+consultas). Como norma general hacemos test automatizados sobre servicios, y puntualmente alguno sobre otro tipo de  elementos.

Como contraste una estructura clásica en java sería:  controladores -> fachadas -> servicios -> daos (daos realizan las consultas).

Espero que te sirva de ayuda, sino ya verás como en cuanto cojas algo de experiencia con Grails ya consigues buscar la mejor solución para cada caso :)

Un saludo