php - metodo - Zend_Framework- ¿Dónde ubicar $_GET y $_POST(solicitud de HTTP)?

php request get (2)

manejar las instrucciones / entrada del usuario (como las solicitudes HTTP) es el trabajo del controlador. modelo es para trabajar / manipular / buscar los datos y ver es para mostrar los resultados al usuario. esto significa que la conexión entre la vista y el modelo es deber de un controlador la mayoría de las veces.

Recientemente leí esta publicación que me llevó a una serie de otras publicaciones que parecen sugerir la misma idea: los modelos lo hacen todo, la Vista debe poder comunicarse directamente con el modelo y viceversa, mientras el Controlador se mantenga fuera del camino. Sin embargo, todos los ejemplos mostrados son bastante simplistas y ninguno realmente muestra un ejemplo de cómo alguien ha intentado implementar el manejo completo de un ciclo de solicitud / respuesta, lo que me hizo preguntarme "¿debería el modelo ser responsable de manejar la solicitud (es decir, $ _GET, $ _POST, etc.) en sí? y "¿el controlador solo debería funcionar como un paso a través para crear instancias del modelo (s) necesario y pasar el (los) modelo (s) a la vista?". (De hecho, encontré un ejemplo tomado al extremo de incrustar un objeto Zend_Form en el modelo)

De mi lectura de lo que dice Fowler sobre MVC y solo controladores en general, parece a primera vista que cuanto más delgada sea la capa de control, mejor. Pero luego me tomé el tiempo de revisar y estudiar lo que dice sobre MVC y Front Controller (que simplemente enturbia las aguas porque ambos patrones definen los controladores) y ahora mis instintos sugieren que Zend_Framework en la implementación de estos dos patrones, en realidad ha creado un objeto compuesto que realiza las funciones de un controlador en MVC y las de un objeto Command en el controlador frontal (o algo así).

Así que me pregunto cuáles serían las opiniones generales de otros que han implementado patrones similares en sus aplicaciones: ¿manejan la solicitud completamente dentro de la capa de controlador o hacen que el modelo tome conciencia de la solicitud y maneje los parámetros directamente dentro del modelo?

Mi primer pensamiento es evitar el manejo de cualquier tipo de solicitud en el modelo. Ese es el trabajo del controlador. Aquí está el por qué: supongamos que tiene un modelo que maneja sus solicitudes (GET o POST). Es probable que esa estructura funcione bien inicialmente. Ahora, supongamos que desea agregar algún tipo de funcionalidad AJAX o poner una interfaz de servicio a su sistema. Ahora que acepta más que simple GET / POST, es decir, JSON o XML, su modelo tendrá que distinguir entre cada tipo de solicitud y saber cómo analizarlos. Creo que eso destruye la simplicidad y la claridad del código del modelo. Estoy de acuerdo en que la capa del controlador debe ser delgada, pero también debe tener un rol y una experiencia. Para mí, la experiencia de un controlador es:

Manejar solicitudes entrantes
Datos de entrega al modelo
Solicitar / aceptar datos del modelo
Pase el modelo de datos a la vista

Vacío sobre cuánto debería saber la vista sobre el modelo. Algunas personas recomiendan que el modelo vaya directamente a la vista, pero creo que es un acoplamiento frágil. A menudo conduce a la lógica en la vista. Además, si está trabajando en un proyecto en el que los miembros del equipo que trabajan en la vista no son tan conocedores de la programación como los principales desarrolladores, les impone una gran carga para mantenerse al día con los cambios. Tiendo a empaquetar los datos que entrego a mis puntos de vista en una estructura neutral en lugar de entregar los modelos completos.

Mi interpretación de MVC es principalmente pragmática. El trabajo del modelo es modelar el dominio en el que está trabajando y no debe importar de dónde provienen los datos. Frecuentemente estructurar el código del modelo con la suposición de que podría usarse fuera de la aplicación web en una aplicación de línea de comandos o una aplicación de escritorio. Ese tipo de unión rara vez ocurre, pero conduce a un claro propósito de cada capa. El trabajo de los controladores es mover los datos entre las partes involucradas, ya sean solicitudes de los clientes, los modelos o la vista. El controlador debe tener muy poca lógica de dominio, pero eso no significa que no tenga ningún código. Finalmente, la vista debería verse bonita. Espero que ayude.