PHP MVC (sin marco), debería estar llamando a una gran cantidad de métodos en mi controlador o modelo?

Question

He estado trabajando en la creación de mi propia aplicación MVC en PHP y he visto un montón de opiniones diferentes en línea acerca de cómo exactamente esto debe ser configurado. Claro, yo entiendo parece que hay un general "Es MVC, que es lo que hacemos de ella" enfoque, pero me estoy quedando en 2 puntos de vista aparentemente contradictorios.

Un poco de historia sobre mi aplicación: estoy usando Smarty como mi presentador y un enfoque orientado a objetos. Parece bastante simple, pero estoy tratando de averiguar el ubicuo "lo que es un modelo" cuestión.

Si tomo un vistazo a algunos tutoriales y marcos, que parecen ver el modelo como estrictamente una clase que hereda métodos dal de una clase abstracta, con un poco extra definen en la clase como sus necesidades de datos difieren de los objetos al objeto. Por ejemplo, podría ver algo como $ productModel-> get (5) que devuelve una matriz de 5 productos de la base de datos. Entonces, ¿qué sucede si necesito consultar múltiples modelos? Cómo puedo almacenar todos los datos en el controlador o una matriz y paso que a la vista? Entonces si estoy dinámicamente a llamar a mi controlador, ¿cómo puedo persistir los datos únicos al controlador necesario para renderizar la vista? Esto parece mal, sobre todo porque luego tienen que pasar cosas como "controllerName", "controllerData", y mi Vista :: render () método se enormemente hinchado con parámetros, a menos que pase en el propio controlador. Tal vez me estoy perdiendo algo.

Vamos a decir que quiero hacer un inicio de sesión que consulta una tabla de usuarios. Inicio de sesión es un modelo o un controlador, dependiendo de ciertas implementaciones que he visto en línea. Algunas implementaciones (la llamaré este método 1) hacer una LoginController para el log () método que podría hacer una comparación de $ _POST y lo que es devuelto desde la instancia de modelo de usuario $ usuario-> get (1) para ver si se valida un usuario . O tal vez de inicio de sesión () podría ser un método en un controlador por defecto. En el otro lado, una aplicación (método de aplicación 2) que se parece más a un enfoque Joomla harían un modelo de sesión y declarar todas las acciones dentro de ello. A continuación, todos los datos que necesita para conseguir asignadas a la vista conseguirían regresar de esos métodos. Así login-> login () sería comprobar realmente puesto, a ver si hay un partido, etc. También el modelo de usuario probablemente se crea una instancia dentro de ese método de modelo.

Mis sentimientos sobre 1: El controlador es la grasa. Además, el controlador está almacenando los datos extraídos de los modelos o pasando en diez mil variables. No parece que trasluchada con la idea de que el modelo debe ser pasar datos a la opinión de que el controlador debería ser incapaces de ver. Además, digamos que yo quiero para envolver todo lo que se encuentra en un modelo específico manejado por un controlador específico en una plantilla externa. Tendría que copie el código de configuración de la plantilla, todo a través de mis funciones de controlador que se interconectan con este modelo. Parece muy ineficiente.

Mis sentimientos alrededor de 2: No tiene por tener acciones que no son métodos de modelo. Si quiero ir a mi raíz del sitio, tengo que hacer un modelo de índice o algo que parece un exceso con el fin de tener un modelo que pasa los datos a la vista. Además, esto no parece ser un enfoque muy popular. Sin embargo, me gusta más porque yo sólo puedo hacer Vista :: render (mymodel-> func ()) y asegurarse de que los datos van a ser pasados ??de vuelta como a mí me gusta sin tener que cagar mi controlador con código la fusión de un millar de resultados de la consulta en conjunto.

He vadeó demasiados argumentos religiosos sobre esto y quieren saber lo que ustedes piensan.

Answer 1

He construido mi propio marco en el pasado también, así que sé lo que estás pasando. He escuchado el dicho "los modelos de acumulación de grasa" y estoy de acuerdo con eso - siempre y cuando el objetivo principal es devolver datos. Consideraba el controlador para ser "El Overlord" ya que manipula datos y dirigí donde debe ir.

Para un controlador de acceso que podría crear algo que como ...

Post URI: http://example.com/login/authenticate

LoginController extends ParentController {
  public function authenticate() {
    $credential_model = $this->getModel('credentials');
    // Obviously you should sanitize the $_POST values.
    $is_valid = $credential_model->isValid($_POST['user'], $_POST['email']);
    $view = $is_valid ? 'login_fail.php' : 'login_success.php';
    $data = array();
    $data['a'] = $a;
    // .. more vars
    $this->view->render($view, $data);
  }
}

En mis datos de opinión siempre debe fluir desde el modelo -> Controlador -> vista, ya que tiene más sentido (datos, manipulación, de salida). La vista sólo debe tener acceso a lo que se le ha dado por el controlador.

En cuanto a esto ...

  

A continuación, si estoy dinámicamente a llamar a mi controlador, ¿cómo puedo persistir los datos únicos al controlador necesario para renderizar la vista?

Bueno, yo se imaginaría usted está construyendo una 'base' o controlador 'padre' que consigue extenderse fuera de sus dinámicamente mediante llamados controladores. Esos controladores niño pueden tener propiedades que son necesarios para el fin de render - sinceramente que iba a necesitar un ejemplo para ir más allá.

Esperamos que esto ayude un poco. Si preguntas más específicas que podría ser capaz de dar una mejor idea a cabo opinión.

Answer 2

Si usted está escribiendo su propia aplicación, creo que la mejor solución es hacerlo usted mismo y descubrir.

En última instancia, lo que tiene más sentido para usted, y lo que hace que sea más fácil para usted para conceptualizar su aplicación y rápidamente agregar o cambiar, va a ser su mejor opción.

Si una forma es "malo", entonces se dará cuenta a través de la experiencia, en lugar de otra persona que le dice. Y sabrá toda la situación mucho mejor, y saber exactamente por qué una forma es mejor.

Lo que me ayudó cuando estaba escribiendo mi propio marco de PHP fue, curiosamente, CherryPy . Esto hizo que el concepto de una aplicación web orientada a objetos tan simple y evidente, y disfruté de usarlo tanto, que modeló la estructura básica de mi framework PHP para imitar CherryPy.

No quiero dar a entender que debe aprender CherryPy. Me refiero a que la sencillez, la claridad, y disfrutar de su propio desarrollo con aplicación web recorrer un largo camino.

---

Si tuviera que dar un consejo específico, yo diría que trato de evitar volver a escribir código; escribir el código para ser reutilizable en otras tantas situaciones como sea posible. Esto no sólo será bueno para su aplicación, pero para aplicaciones futuras que puede escribir o trabajar.

Es posible que echa un vistazo a de Eric S. Raymond programación para Unix . Creo que son definitivamente aplicable en este caso.