A veces tenemos algo de lógica empresarial representada en el código del controlador de nuestras aplicaciones. Esta suele ser la lógica que diferencia qué métodos llamar del modelo y / o qué argumentos transmitir.
Otro ejemplo de esto es un conjunto de funciones de utilidad que existen en el controlador que pueden funcionar para formatear o desinfectar los datos devueltos por el modelo, de acuerdo con un conjunto de reglas comerciales.
Esto funciona, pero me pregunto si está coqueteando con el desastre. Si existe una lógica empresarial compartida entre el controlador y el modelo, las dos capas ya no son separables, y alguien que herede el código puede confundirse por esta irregularidad en la ubicación del código relacionado con la lógica empresarial.
Mi pregunta es ¿cuánta lógica empresarial debe permitirse en el controlador y en qué circunstancias, si corresponde?
fuente
Respuestas:
Idealmente ninguno
Pero eso no siempre es posible. No puedo darte números duros como 20% o 10 líneas, eso es subjetivo hasta el punto de que no se puede responder. Puedo describir cómo uso patrones de diseño y circunstancias que requieren doblarlos ligeramente.
En mi opinión, depende completamente del propósito de la aplicación. ¿Construir una API REST simple para publicar? Olvídate de la separación limpia o incluso de un patrón. Puede producir una versión funcional en menos de una hora. ¿Construyendo algo más grande? Probablemente sea mejor trabajar en ello.
Construir sistemas contenidos individualmente es el objetivo. Si comienza a escribir lógica de negocios que es específica de cómo interactúan dos sistemas, eso es un problema. Sin profundizar en ello, no puedo opinar.
Los patrones de diseño son moldes, a algunos les gusta adherirse estrictamente a ellos sobre la base de un código principal y bien escrito. Cumplir estrictamente con un patrón probablemente no le dará un código incorrecto , pero podría tomar más tiempo y hacer que escriba mucho más código.
Los patrones de diseño son flexibles, ajústelos para satisfacer sus necesidades. Doblarlos demasiado y se rompen sin embargo. Sepa lo que necesita y elija un patrón de diseño más cercano a eso.
fuente
Tan poco como sea posible. Preferiblemente ninguno.
El controlador debe preocuparse por aceptar la solicitud, solicitar al servicio de dominio correcto que procese la solicitud y entregar la respuesta a la vista correcta.
En ese proceso, toda la "lógica de negocios" debe existir en los servicios de dominio.
Si tiene una funcionalidad que toma objetos de dominio y crea modelos de vista a partir de ellos, entonces eso puede coexistir razonablemente con el controlador. Pero ese debería ser un código que existe solo por el bien de las vistas correspondientes. Si existe una regla de nivel empresarial sobre la desinfección de datos, debe existir en su dominio / nivel de servicio (con las pruebas unitarias apropiadas).
fuente
El término "lógica de negocios" es a menudo confuso porque las personas tienen diferentes opiniones sobre lo que esto significa. En mi opinión, el término "lógica de negocios" cubre dos áreas
La lógica de dominio es una lógica relacionada con el área central con la que se relaciona su negocio, por lo que si escribe una solicitud para contadores, las reglas de impuestos, las reglas de contabilidad, etc., son parte de la lógica de dominio.
La lógica de la aplicación es lógica relacionada con el hecho de que está ejecutando un programa de computadora. Esto puede ser cosas como la exportación de importación CSV, asistentes, etc. También podría contener cosas como la creación de correos electrónicos de contraseña olvidados.
El tipo de "lógica de negocios" que puede colocar en la capa del controlador es la lógica de aplicación. Quizás no toda la lógica de la aplicación debería ir allí. Pero nunca debe colocar la lógica de dominio en la capa del controlador. Eso obviamente debería estar en la capa de dominio.
Estaba hablando de lógica para formatear o desinfectar datos. El formateo definitivamente debe ser la lógica de la aplicación. La desinfección por otro lado podría ser lógica de dominio, si la desinfección de datos se basa en reglas de dominio. Eso depende del contexto.
fuente
Los controladores deben ser muy ligeros en la lógica de dominio.
Los controladores deben delegar tareas tales como recuperar un registro del almacén de datos a través de una capa de servicio / repositorio abstraído y devolver los datos al almacén de datos por el mismo servicio (o relacionado). En cuanto a la mecánica y el trabajo más fino entre esas operaciones, generalmente pertenecen a otro lugar que no sea el controlador.
A menudo me encuentro agregando pequeños métodos de saneamiento de datos a mis controladores que guardan los datos en la tienda y, aunque esta es una solución efectiva, no encaja bien con la función prevista del controlador. Idealmente, cualquier cosa que esté modificando, validando o analizando su modelo debería ocurrir muy cerca, si no dentro, del modelo mismo. Por ejemplo, si necesita 'limpiar' un objeto modelo antes de almacenarlo, considere tener un método SanitizeInputs () en el modelo o como parte del servicio que maneja el almacenamiento del modelo.
fuente
Desde un punto de vista pragmático, descubrí que uno termina con la lógica en su controlador o el comportamiento del controlador en su modelo cuando intenta hacer algo para lo que no hay un buen enfoque que cumpla con los patrones. Doblemente si está escribiendo una aplicación que no tiene una gran infraestructura detrás de ella.
Puede ir en cualquier dirección, pero por lo general trato de pensar si es probable que aparezca algo extraño en más de una acción del controlador, si es así, en el modelo. Si eso no está claro, trato de pensar si es más "apropiado" en un lugar que en el otro. De lo contrario, generalmente lo pongo en el modelo solo para mantenerlo fuera del controlador (preferencia personal para controladores más pequeños y objetos de datos más fuertes, YMMV)
Una tercera opción sería hacer referencia a los elementos de utilidad como una clase de utilidad separada, pero en opinión de muchos, esto también está en contra del patrón.
Además, solo porque no estás siguiendo estrictamente un patrón, no estás necesariamente coqueteando con el desastre. A menos que realmente espere una cantidad significativa de reutilización de código de este proyecto, me preocuparía mucho más que el proyecto sea coherente consigo mismo (es decir: no cambie de lugar dónde coloca estos bits una vez que elige una ubicación) que una reescritura que por alguna razón quiere salvar parte del medio del proyecto. Documente / comente dónde y por qué se desvió del patrón común y defina el patrón esperado para esta aplicación.
MVC fue una desviación de los patrones establecidos en sí mismo en un punto.
fuente
Al igual que muchos otros conceptos interesantes en la programación, MVC es un paradigma poderoso para brindar estructura y enfoque a una familia de estrategias cercanas o similares para implementar ciertos escenarios.
Al igual que muchos otros conceptos de programación, MVC simplifica la realidad, descarta pequeños detalles y proporciona un modelo de estructura alámbrica para seguir. Al igual que muchas otras simplificaciones de la realidad, funciona al llevar la estructura al caos como lo ve una mente humana.
Aún así, como muchos otros conceptos de programación, MVS es solo una simplificación de la realidad. No es perfecto ni completo. Es por eso que no es posible adaptar un escenario del mundo real a un modelo demasiado simplificado. De ahí surgen muchas preguntas similares a esta.
¿Cuánta lógica debe entrar en un controlador?
Si una vista debe contener alguna lógica condicional?
¿Debe un modelo contener datos adicionales que no se encuentran directamente en las entidades comerciales?
Todas estas preguntas nacen en un intento de ajustar el código para que se ajuste a la idea conceptual de MVC de manera precisa y completa.
Mi respuesta para ti es no intentarlo. MVC proporciona estructura. Cree su aplicación en torno a esta base, pero no espere que se ajuste perfectamente. Habrá desviaciones, es normal. Solo mira para mantenerlos bajo control.
fuente