Procesamiento de formularios PHP: ¿distribuido o centralizado?

He buscado alrededor, pero no parece haber un consenso claro sobre cuál es mejor. Actualmente, todos los formularios HTML en el sitio apuntan a un único archivo PHP. Cada formulario tiene una entrada oculta que especifica la acción (por ejemplo, ‘inicio de sesión de usuario’, ‘cierre de sesión de usuario’) y los métodos de llamadas de archivos PHP a partir de eso.

Entonces mi pregunta es: ¿Debería volver a señalar cada formulario consigo, los formularios relacionados a un único archivo o todos los formularios a un solo archivo? Y en términos de MVC, ¿el procesamiento debería tener lugar en el controlador o formulario?

¿Debería señalar cada formulario consigo mismo, los formularios relacionados a un único archivo o todos los formularios a un solo archivo?

Debería apuntar todo a index.php , que luego delega otros componentes (controladores en términos de MVC) para encargarse del procesamiento. El controlador decidirá qué vista quiere renderizar. index.php sería en este caso algo que llamamos el controlador frontal . ( nota : a continuación, estoy recomendando ZF1 como una plataforma de aprendizaje. ZF1 tiene una clase de “controlador frontal.” Algunas personas pueden argumentar que ESO es el controlador frontal y index.php es lo que ellos llaman el script de entrada . En mi opinión, eso es solo el segundo controlador “frontal”. Sin embargo, ambas opiniones son controvertidas, así que haga su propia opinión).

Y en términos de MVC, ¿el procesamiento debería tener lugar en el controlador o formulario?

En términos de POO en primer lugar: el objeto es el único que sabe cómo validar sus propios datos (el principio de autocontención ), por lo que la forma debe validarse a sí misma. Si se trata de un modelo, el modelo debe ser llamado por el controlador o por el formulario, es cuestión de gustos. No importa de qué manera, se aplica el mismo principio: alimenta el Modelo con datos y llama a su método de validación.

Como habrás notado, la clase Form es un Model .

No te dejes engañar por el bombo llamado MVC. Respete los principios de OOP sobre todo .

En cuanto a MVC: el patrón MVC dice: el controlador solo coordina los otros componentes, por ejemplo, toma la entrada, crea una instancia de Formulario y llama al método de validación del Formulario.

Te aconsejo que uses un marco para ver mejor cómo funcionan todas estas piezas juntas. Lo mejor sería zend framework 1, que tiene poco que ver con los requisitos de la vida real, PERO que es una obra maestra en términos de patrones y prácticas.

Quizás ZF2 cambie ese error con el controlador frontal adicional.


En cuanto a las otras respuestas, siento la necesidad de aclarar algunos términos utilizados en mi respuesta:

  • Model es un modelo. Hay mucha documentación sobre MVC
  • Form es una subclase de Model . Se encarga de la validación. También puede tener un método Form::__toString() que representa el formulario HTML en la vista (el V en MVC)
  • view es el archivo html, y se procesa bajo la supervisión del controlador (C en MVC)

Para recapitular, el flujo de ejecución general se vería así:


  1. script de entrada (un controlador frontal)
  2. enrutador (decide a qué controlador reenviar la solicitud)
  3. el Controller coordina todas las acciones, llamando al Model::validate() de uno o varios modelos (incluido el Form , que también es un Model )
  4. al final, el Controller elige render() una vista (un archivo html), que podría contener una llamada a Form::__toString() , en cuyo caso el Form es un híbrido de Model y "renderizador".
  5. Divertido
  6. Lucro

Eso es todo, básicamente. Diferentes marcos tienen diferentes flujos de datos / ejecución. ZF1 se ve así por ejemplo: http://www.slideshare.net/polleywong/zend-framework-dispatch-workflow

En términos MVC su procesamiento debe tener lugar en el controlador. No debe tener ninguna lógica de procesamiento en su formulario (la vista). Si usted tiene un controlador diferente para cada formulario, depende de usted. Podría, por ejemplo, tener un único controlador que acepte todas las presentaciones de formularios y realice algunos procesos comunes (como la detección de csrf) y luego invoque sus otros controladores para cada formulario. Alternativamente, podría tener un único controlador que cargue los requisitos de validación desde una base de datos y se comporte de manera diferente según el formulario que se haya enviado.

En términos de MVC, hacer que todo el formulario apunte a una sola secuencia de comandos significa que tiene un Front-Controller for Forms . Hay un controlador que se ocupa de las solicitudes de formulario.

¿Debería señalar cada formulario consigo mismo, los formularios relacionados a un único archivo o todos los formularios a un solo archivo?

Eso depende de sus necesidades y el diseño tal vez incluso la architecture de su sitio.

Y en términos de MVC, ¿el procesamiento debería tener lugar en el controlador o formulario?

El procesamiento en MVC normalmente tiene lugar dentro de los controladores (solo ligeramente) y los modelos (procesamiento pesado). Entonces, si está buscando una implementación de diseño MVC ejemplar, lo más probable es que tenga Modelos de formulario que los Controladores utilicen.

Esto asegurará que pueda hacer que los formularios sean más flexibles y que no duplique el código para el procesamiento de formularios dentro de su aplicación.

En mi opinión, debes usar un archivo para cada propósito. Al igual que la estructura de mvc, este es un buen enfoque para la progtwigción y será útil cuando el código se vuelva realmente complicado.

Su pregunta se relaciona estrechamente con el patrón del controlador frontal . En mi opinión, no pierde nada al apuntar muy bien a un determinado guión, pero gane la flexibilidad, ejecute ciertas acciones sin tener que repetir (y probablemente fingir en algún lugar) esas acciones.

Así que recomendaría señalar todas las formas a una secuencia de comandos.

Por cierto. es el controlador quien maneja el procesamiento de formularios en términos de MVC web.

Siguiendo mi comentario sobre la respuesta de Flavio …

El objeto que encapsula el formulario se debe usar tanto para presentar el formulario al usuario como para recuperar los datos enviados por el usuario. El uso de 2 conjuntos de códigos diferentes para operar en el mismo conjunto de datos socava el principio de encapsulación. Considere si su formulario de inicio de sesión tiene un nombre y un campo de contraseña. Si decide que quiere procesar un hash sha1 de la contraseña en lugar del valor original, ¡tendrá que modificar 2 bits de código en 2 lugares diferentes!

Esto no significa que ambas instancias del objeto de formulario deben implementarse dentro de la misma ruta de URL; considere las construcciones ‘require’ y auto_include de PHP.

Cuando múltiples conjuntos de entrada se multiplexan a través de la misma ruta URL, esto se conoce como un patrón de Controlador Frontal.

Existen ventajas y problemas con Front Controller frente al enfoque más distribuido.

Controlador frontal:

  • permite que el procesamiento común se implemente en un solo lugar (por ejemplo, autorización, registro)
  • mueve la estructura de la aplicación fuera del diseño del sistema de archivos y en el código, por lo tanto, controla la estructura de la aplicación implementada dentro del código
  • simplifica el manejo de marcadores

Controlador no frontal:

  • mucho más fácil de apoyar
  • estructura de la aplicación evidente de los registros del servidor web
  • más robusto, ya que al romper una secuencia de comandos no se rompe el sitio completo
  • mejor rendimiento: no es necesario cargar grandes cantidades de código redundante / carga diferida del objective de procesamiento