2009-02-24 15 views
7

Tengo una pregunta que realmente se aplica a cualquier marco MVC, estoy usando Zend Framework MVC.¿Cómo debería nombrar su controlador en MVC? ¿Cuándo deberías crear uno nuevo?

¿Cuándo exactamente debería crear un nuevo controlador? ¿Qué debería exactamente definir la capa del Controlador?

He creado varias aplicaciones con MVC, que se vuelven cada vez más reutilizables, pero siempre me ha costado nombrar las clases de controladores. En su mayor parte, coincide con las solicitudes de URL que existen, por lo que la lógica de negocio/front-end. Pero en algunos casos parece totalmente arbitrario.

¿Alguien tiene alguna heurística/pautas a seguir? Parece que con todo el bombo sobre MVC, especialmente con PHP, hay pocos datos sobre convenciones y heurísticas reales. Como es bastante fácil crear una aplicación MVC desorganizada ...

Respuesta

7

Generalmente tengo un controlador para cada grupo lógico de funciones. A menudo esto corresponderá con un controlador por modelo, a veces no.

Imagine que está creando un catálogo en línea simple que muestra una lista de categorías y luego cuando el usuario selecciona una categoría, muestra una lista de productos de esa categoría, junto con un panel de administración para operaciones CRUD en categorías y productos. Tendría dos modelos (CategoryModel y ProductModel). Tendría un controlador que generaba los listados de categorías para la interfaz y otro controlador que generaba los listados de productos (por ejemplo, CategoryController y ProductController). Entonces tendría un controlador para categorías y productos en el back-end (AdminCategoryController y AdminProductController). Los dos controladores de back-end manejarían las operaciones de lista/agregar/editar/eliminar/ver para sus respectivos modelos. Si piensa en la estructura de su URL y coloca funciones relacionadas en las URL relacionadas, entonces la estructura de su controlador a menudo coincidirá con su estructura de URL. De hecho, algunos marcos (por ejemplo, CodeIgniter) enrutan las solicitudes en función del nombre del controlador como comportamiento predeterminado.

En cuanto a lo que se incluye en los controladores, trabajo en la idea de que los Modelos son para acceso a datos, y envuelven y ocultan la estructura de la base de datos. La lógica como "asignar la hora actual a la fecha de finalización cuando el estado está configurado como 'completo'" es un gran modelo de ajuste.

Las vistas contienen la totalidad de su presentación. Controladores/Modelos no deben generar o manejar HTML. Las decisiones como 2 columnas o 3 pertenecen a las vistas. La lógica de las vistas debe restringirse a lo que se requiere para generar la salida visible. Si desea consultar la base de datos desde una vista, probablemente esté aplicando demasiada lógica a la vista.

Los controladores son para lo que queda. Generalmente eso significa, validar la entrada, asignar datos de formulario a los modelos, seleccionar las vistas correctas y crear instancias de los modelos necesarios para manejar la solicitud.

+0

Gracias .... eso es más o menos lo que estoy haciendo. Una cosa que trato de hacer es poner más lógica en la capa del modelo. Uso objetos de modelo de propel y pensaba que la validación debería ir a la capa de modelo. El controlador solo establece los datos en el modelo ... – AndreLiem

+1

Algunos desarrolladores prefieren poner toda la validación en los Modelos. Encuentro que la validación del formulario se realiza mejor en el Controlador (porque está estrechamente vinculado a la IU) y la validación básica del tipo de datos (por ejemplo, restringir un campo de enumeración a determinados valores) funciona bien en un modelo. –

0

En general sigo el patrón de controlador por modelo. Tengo algunos controladores que pueden servir varios modelos (como el controlador de administración que sirve varios modelos administrativos), pero la regla general es un controlador por modelo de negocio.

Cuestiones relacionadas