Modelos de grasa, controladores delgados y el patrón de diseño MVC

Question

Acabo de leer un blog post que explica MVC con una analogía bancaria. Tengo algunos meses de experiencia en el desarrollo de aplicaciones web con un framework MVC (CakePHP), así que obtengo los conceptos básicos, pero comencé a ver un tema que me hizo pensar que estoy tomando un enfoque erróneo en cuanto a dónde puse mi lógica:

• modelos gordos, flacos controladores
• mantener la mayor cantidad lógica de negocio en los modelos de lo posible

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

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

• La aplicación tiene listas, que contienen artículos, y los artículos pueden ser clasificados. La lógica de clasificación que coloca la lista en orden de clasificación está en un controlador.
• De forma similar, los elementos (modelo de artículo) también tienen imágenes (modelo de imagen). Cada elemento puede tener una imagen predeterminada (designada por image_id en la tabla de elementos). 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 anteriormente, estoy en el camino correcto al pensar que esos son los casos de la lógica actualmente en un controlador que pertenece en un modelo?
2. ¿Cuáles son algunas otras áreas de lógica, comunes a las aplicaciones web, que deberían incluirse 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 esos ejemplos que di más arriba y trato de mover esa lógica a un modelo, no sabría por dónde empezar . ¿Puede alguien señalarme en la dirección correcta publicando aquí algún código o vinculándome a algunos buenos recursos de aprendizaje? La ayuda específica de CakePHP sería genial, pero estoy seguro de que cualquier MVC será suficiente.

Answer 1

Es un poco difícil de darle las respuestas "correctas", ya que algunas de ellas están relacionadas con las características específicas del marco (independientemente de los que se está trabajando).

Por lo menos en términos de CakePHP:

1. Sí

2. Cualquier cosa que se ocupa de los datos o la manipulación de datos debe estar en un modelo. En términos de CakePHP, ¿qué pasa con un método simple de find()? ... Si existe la posibilidad de que haga algo "especial" (es decir, recuerde un conjunto específico de "condición"), que podría necesitar en otro lugar, esa es una buena excusa para ajustar el método de un modelo.

3. Lamentablemente, nunca es una respuesta fácil, y la refacturación del código es un proceso natural. A veces solo te despiertas: "macarrones sagrados ... ¡eso debería estar en la miniatura!" (bueno, tal vez no lo haga, pero tengo :))

Answer 2

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

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

2) Me pregunto: ¿y si añadiera otra forma de utilizar estas clases, tendría que duplicar la funcionalidad de una manera que sea casi de 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