En demasiadas ocasiones, al hablar de MVC, es habitual traducir “modelo” por “modelo datos”. Supongo que yo mismo lo he confundido a menudo en el pasado. Quizás por pura vagancia. La realidad es creo que no debería ser así y es lo que intento transmitir desde hace unos años ya, aunque la realidad me demuestra que es más difícil de lo que parece. Supongo que “comernos” palabras o los muchos modelos que hay y sus sinónimos, variaciones y perversiones (modelo de la aplicación, modelo de datos, modelo de negocio, o simplemente “modelo”) lo hace más complicado de lo que debería ser .
La M de MVC, y la definición del patrón lo deja claro, debería entenderse como “modelo de negocio”. Es decir, tanto los datos como las acciones que se ejecutan sobre ellos. Es decir, no deberíamos en el controlador, por ejemplo una acción de Struts, realizar estas operaciones (por ejemplo: calcular los costes de envío de un pedido), sino que deberíamos convertir los datos de entrada, etc. para después llamar a la parte del modelo que se encarga de eso. Esta división, que es más o menos la que aparece en la figura, nos permite además aislar las distintas partes favoreciendo la reutilización, las pruebas, los cambios, etc.
En Java existen frameworks con bastante solera que siguen “Model-driven architecture”. En esta arquitectura la aplicación se define casi completamente a partir del Modelo (modelo de datos negocio metadatos de presentación).
La vista y el control vienen dados por el framework.
No se genera la típica presentación CRUD, sino que se tienen en cuenta las operaciones de negocio que se pueden realizar sobre esos datos.
Lógicamente, partes de la vista se pueden personalizar según sea necesario.
Para saber más:
http://nakedobjects.org/
http://www.jmatter.org/
Hola,
tal como dices, se puede llegar a confundir muy facilmente lo que es modelo y lo que no. He tenido la suerte de trabajar con aplicaciones j2ee tanto con clientes swing como con clientes web, y tal eso me haya dado una vision más clara de que es qué debe estar en el modelo y qué debe estar en el controlador. El fácil y sencillo truco que sigo es ponerme en el punto de vista de tener otro tipo cliente, es decir si estoy con, por ej struts, pienso que llamada al modelo tendría que hacer un cliente swing y salgo de dudas rápidamente. Como bien dices esto facilita mucho la reutilización y los cambios, porque sino puedes encontrarte con muuuchos sitios en el código donde se hace lo mismo.
saludos