ágil tutorial symfony2 español descargar desarrollo con php model-view-controller symfony

php - tutorial - Symfony2 MVC: ¿a dónde pertenece mi código?



symfony php tutorial (3)

Respuesta corta:

La generación de PDF debe ser un servicio, no un método en un objeto.

Respuesta más larga:

En general, y especialmente en Symfony2, los modelos solo deberían usarse para almacenar datos. Los controladores se utilizan para manipular las relaciones entre los modelos, y las Vistas se utilizan para expresar los datos en forma legible por humanos o por computadora. Los servicios son para cosas que realmente no se ajustan a ninguna de las anteriores, cosas que no tienen que ver con el estado de su aplicación web.

Un buen ejemplo es enviar correos electrónicos. Los correos electrónicos contienen datos (modelo). Los usuarios han enviado correos electrónicos (controlador). Los correos electrónicos se ven de cierta manera (ver). Sin embargo, el hecho de enviar correos electrónicos es independiente del estado de la aplicación web (todo el servicio sabe que se le solicitó que enviara este correo electrónico a estas personas). Por lo tanto, tiene sentido que haya un servicio independiente que solo maneje el envío de correos electrónicos.

Del mismo modo, el acto de generar archivos PDF es independiente del estado de la aplicación web. Un generador de PDF no necesita saber qué está pasando en su aplicación, simplemente sabe que se le pidió que hiciera un PDF.

Estoy buscando aclaraciones sobre si poner código en un controlador, una entidad o hacer un servicio.

Tengo objetos ''cardset'' y ''card'' (donde muchos de estos últimos están incrustados en el primero, MongoDB), representados por clases / objetos PHP normales. Estos contienen atributos, por ejemplo, ''id'', ''postal_address''.

Tengo un método que genera un PDF de una tarjeta. Actualmente tengo eso dentro del objeto ''Tarjeta'' así que desde un Controlador puedo llamar:

$card->makePDF()

Eso parece limpio y OO para mí, pero sospecho que estoy equivocado.

Si pongo toda la lógica en el controlador que se vuelve larga y difícil de manejar, y no estoy seguro de que el controlador sea el lugar para los métodos que actúan sobre mis objetos. ¿Para eso sirven los servicios?

Intentar resumir: un objeto debe conocer todas las cosas comunes que podría hacer ''a sí mismo'' y tenerlas dentro como funciones de miembro, o deberían pasar los métodos en cualquier otro lado al objeto sobre el que actuar. De ser así, ¿dónde deberían guardarse esos métodos?

Estoy bastante seguro de que no es un ''Repositorio'' porque parece ayudar a recuperar / almacenar entidades.

¡Gracias!


  • Symfony2 NO es una estructura MVC (como dijo el propio Fabien) precisamente porque da todos los V (ramitas) y C (controladores) pero NO da la parte M. La parte M es "libre" para ser construida como lo desee.

  • Hay una confusión importante, la gente "piensa" que la Doctrina ES el modelo. Pero eso no es verdad Lo que hacemos es DOS directorios en el paquete, uno llamado "Documento" para las clases Doctrine-ODM y otro llamado "Modelo" donde reside la "lógica comercial".

Personalmente, veo que $ card-> makePDF () tiene sentido ...

Pero $ card debe ser una "tarjeta modelo", que hereda o tiene un objeto subyacente "tarjeta de datos" que es la clase de doctrina.

Puedes jugar con la herencia, o con interfaces, con creadores o lo que quieras relacionar "modelo-tarjeta" con "tarjeta de datos", pero la clave es que "la doctrina no es un modelo de NEGOCIO" es simplemente una capa de persistencia y tu modelo son "clases simples" que puede compilar para ajustar sus datos y hacer que los controladores consuman el modelo, no los datos.


Si sigue los principios SÓLIDOS , obtendrá el SRP que establece que su clase debe tener una sola responsabilidad.

Creo que es obvio que generar un pdf es algo diferente de modelar datos y mapear su base de datos (su entidad lo hace)