Modelos Fat, controladores skinny y el patrón de diseño MVC


Acabo de leer una entrada de blog que explica MVC con una analogía bancaria. Tengo unos meses de experiencia con el desarrollo de aplicaciones web con un marco MVC (CakePHP), así que entiendo lo básico, pero empecé a ver un tema que me hizo pensar que estoy tomando un enfoque defectuoso a donde pongo mi lógica:

  • Modelos gordos, controladores flacos
  • Mantenga tanta lógica de negocios en los modelos como sea posible

En mi aplicación, los modelos son anoréxicos y los controladores son obesos. Tengo toda la lógica de negocio en los controladores y nada más que asociaciones y reglas de validación en los modelos.

Al escanear a través de mis controladores, ahora puedo identificar una gran cantidad de lógica que probablemente debería ir en un modelo:

  • La aplicación tiene listas, que contienen elementos, y los elementos se pueden clasificar. La lógica de ordenación que pone la lista en orden de clasificación está en un controlador.
  • Del mismo modo, los elementos (modelo de elemento) también tienen imágenes (Modelo de imagen). Cada elemento puede tener una imagen predeterminada (designado por image_id en la tabla items). Cuando se muestra un elemento con sus imágenes, la imagen predeterminada debe aparecer primero. Tengo la lógica que hace esto en un controlador.
  • Cuando se muestra una lista, las listas relacionadas se muestran en la barra lateral. La lógica para determinar qué listas están relacionadas está en un controlador.

Ahora a mis preguntas:

  1. Con los ejemplos que di arriba, estoy en el camino correcto al pensar que esos son ejemplos de lógica actualmente en un controlador que pertenece a un modelo?
  2. ¿Cuáles son algunas otras áreas de la lógica, comunes a las aplicaciones web, que deberían entrar en los modelos?
  3. Estoy seguro de que identificar este problema y cambiar mi patrón de diseño es la mitad de la batalla, pero incluso si decido tomar los ejemplos que di arriba y tratar de mover esa lógica a un modelo, no sabría por dónde empezar. ¿Alguien puede indicarme en la dirección correcta publicando algún código aquí, o enlazando a algunos buenos recursos de aprendizaje? CakePHP ayuda específica sería genial, pero estoy seguro de que cualquier MVC será suficiente.
Author: Ciaran, 2009-01-22

2 answers

Es un poco difícil darle las respuestas "correctas", ya que algunas de ellas tratan con los detalles del framework (independientemente de los que esté trabajando).

Al menos en términos de CakePHP:

  1. Cualquier cosa que se ocupe de datos o manipulación de datos debe estar en un modelo. En términos de CakePHP, ¿qué pasa con un simple método find ()? ... Si hay una posibilidad de que va a hacer algo "especial" (es decir, recordar un conjunto específico de 'condición'), que usted podría necesitar en otro lugar, esa es una buena excusa para envolver dentro del método de un modelo.

  2. Desafortunadamente, nunca hay una respuesta fácil, y la refactorización del código es un proceso natural. A veces te despiertas y dices: "Santos macarrones... ¡eso debería estar en el modelo!"(bueno, tal vez usted no hace eso, pero tengo :))

 55
Author: vladko,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-04-12 13:25:08

Estoy usando al menos estas dos 'pruebas' para comprobar si mi lógica está en el lugar correcto:

1) Si escribo un unittest, es fácil crear solo el objeto 'real' para hacer la prueba (= el objeto que está utilizando en producción) y no incluir muchos otros, excepto quizás algunos objetos de valor. Necesitar tanto un objeto modelo real como un objeto controlador real para hacer una prueba podría ser una señal que necesita para mover la funcionalidad.

2) Hazme la pregunta: ¿qué pasa si agrego otra forma de usar estas clases, ¿tendría que duplicar la funcionalidad de una manera que sea casi copiar y pegar? ... Esa también es probablemente una buena razón para mover esa funcionalidad.

También interesante: http://www.martinfowler.com/bliki/AnemicDomainModel.html

 19
Author: Simon Groenewolt,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-01-21 22:33:17