model view controller - ventajas - Modelos gordos, controladores delgados y el patrón de diseño MVC

mvc pdf

Question

Acabo de leer una publicación de blog 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, controladores flacos
• Mantenga la mayor 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 comercial en los controladores y nada más que asociaciones y reglas de validación en los modelos.

Escaneando a través de mis controladores, ahora puedo identificar mucha lógica que probablemente debería ir en un modelo:

• La aplicación tiene listas, que contienen elementos, y los artículos se pueden clasificar. La lógica de clasificación que coloca la lista en orden de clasificación está en un controlador.
• Del mismo modo, 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 más arriba, ¿estoy en el camino correcto al pensar que esos son casos de lógica actualmente en un controlador que pertenece a 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 darle las respuestas "correctas", ya que algunas de ellas abordan las características específicas del marco (independientemente de con las que esté trabajando).

Al menos en términos de CakePHP:

1. Sí

2. Todo lo que tenga que ver con la manipulación de datos o 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. Desafortunadamente, nunca hay 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, quizás no hagas eso, pero tengo :))

Answer 2

Estoy utilizando al menos estas dos "pruebas" para verificar si mi lógica está en el lugar correcto:

1) Si escribo una prueba unitaria, 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 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) Hágase la pregunta: ¿y si añadiera otra forma de utilizar estas clases, necesitaría 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 es interesante: http://www.martinfowler.com/bliki/AnemicDomainModel.html