Este grupo redactor ha pasado horas investigando la resolución a tu duda, te ofrecemos la respuestas por eso esperamos que te resulte de gran apoyo.
Solución:
Puede que no sea la mejor idea considerar Rails como un elemento básico del patrón de diseño MVC. Dicho marco se creó con algunas deficiencias inherentes (lo elaboré un poco en una publicación diferente) y la comunidad recién ahora ha comenzado a abordar las consecuencias. Podría considerar el desarrollo de DataMapper2 como el primer paso importante.
Alguna teoria
Las personas que dan ese consejo parecen estar afectadas por un concepto erróneo bastante común. Así que déjame empezar por aclararlo: El modelo, en el patrón de diseño moderno de MVC, NO es una clase u objeto. El modelo es una capa.
La idea central detrás del patrón MVC es Separación de intereses y el primer paso es la división entre la capa de presentación y las capas del modelo. Al igual que la capa de presentación se divide en controladores (instancias, responsables de manejar la entrada del usuario), vistas (instancias, responsables de la lógica de la interfaz de usuario) y plantillas / diseños, también lo hace la capa de modelo.
Las partes principales que componen la capa del modelo son:
-
Objetos de dominio
También conocidos como entidades de dominio, objetos comerciales u objetos modelo (no me gusta este último nombre porque solo aumenta la confusión). Estas estructuras son lo que la gente suele llamar erróneamente “modelos”. Son responsables de contener las reglas comerciales (todas las matemáticas y la validación de una unidad específica de lógica de dominio).
-
Abstracciones de almacenamiento:
Por lo general, se implementa utilizando un patrón de mapeador de datos (no lo confunda con los ORM, que han abusado de este nombre). Estas instancias generalmente tienen la tarea de almacenar y recuperar información en los objetos de dominio. Cada objeto de dominio puede tener varios mapeadores, al igual que existen varias formas de almacenamiento (base de datos, caché, sesión, cookies, / dev /null).
-
Servicios:
Estructuras responsables de la lógica de la aplicación (es decir, interacción entre objetos de dominio e interacción entre objetos de dominio y abstracciones de almacenamiento). Deben actuar como la “interfaz” a través de la cual la capa de presentación interactúa con la capa del modelo. Esto suele ser lo que en el código similar a Rails termina en los controladores.
También hay varias estructuras que pueden estar en los espacios entre estos grupos: DAO, unidades de trabajo y repositorios.
Oh … y cuando hablamos (en el contexto de la web) sobre un usuario que interactúa con la aplicación MVC, no es un ser humano. El “usuario” es en realidad su navegador web.
Entonces, ¿qué pasa con las deidades?
En lugar de tener algún modelo aterrador y monolítico con el que trabajar, los controladores deberían interactuar con los servicios. Pasas datos de la entrada del usuario a un servicio específico (por ejemplo MailService o RecognitionService). De esta manera, el controlador cambia el estado de la capa del modelo, pero se hace usando una API clara y sin alterar las estructuras internas (lo que causaría una abstracción con fugas).
Dichos cambios pueden causar una reacción inmediata o solo afectar los datos que la instancia de vista solicita de la capa del modelo, o ambos.
Cada servicio puede interactuar con cualquier número (aunque, por lo general, es solo un puñado) de objetos de dominio y abstracciones de almacenamiento. Por ejemplo, el RecogitionService No podría importarle menos las abstracciones de almacenamiento de los artículos.
Notas de cierre
De esta manera, obtiene una aplicación que se puede probar unitariamente en cualquier nivel, tiene un bajo acoplamiento (si se implementa correctamente) y tiene una arquitectura claramente comprensible.
Sin embargo, tenga en cuenta: MVC no está diseñado para aplicaciones pequeñas. Si está escribiendo una página de libro de visitas usando el patrón MVC, lo está haciendo mal. Este patrón está destinado a hacer cumplir la Ley y el orden en aplicaciones a gran escala.
Para las personas que usan PHP como idioma principal, esta publicación puede ser relevante. Es una descripción un poco más larga de la capa del modelo con algunos fragmentos de código.
Si las clases “modelo” se implementan de manera deficiente, sí, su preocupación es relevante. Una clase modelo no debería estar haciendo correo electrónico (tareas de infraestructura).
La verdadera pregunta es qué implica el modelo en MVC. No está restringido a las clases POCO con algunos métodos. Modelo en MVC significa lógica de datos y negocios. Trátelo como un superconjunto de modelos básicos clásicos de POCO.
Ver ==== Controlador ==== Modelo —> Capa de proceso empresarial -> Modelos centrales
Agregue ensamblajes de infraestructura y capas de acceso a datos y use la inyección para entregar eso en el BPL, entonces su proceso está usando MVC según lo previsto.
BPL puede invocar patrones de UoW / Respository y ejecutar reglas comerciales y llamar a funciones de infraestructura mediante objetos inyectados o patrones de interfaz.
Por lo tanto, la recomendación de mantener un controlador delgado no significa que la clase “persona” en un modelo Core clásico deba tener 50 métodos y llamar directamente al correo electrónico. Tienes razón al pensar que esto está mal.
Es posible que aún se requiera que el controlador cree una instancia e inyecte clases de infraestructura en el BPL o la capa central si se llama directamente. Debe haber una capa empresarial o al menos clases que orquestren las llamadas en las clases del modelo de objetos clásicos. Bueno, esa es mi “vista” de todos modos 😉
Para una versión genérica de MVC, la descripción wiki http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Un pequeño blog que habla de la “M” en MVC. http://www.thedeveloperday.com/skinny-controllers/