php - tutorial - ¿Puedo llamar un Modelo desde una Vista?
mvc php pdf (4)
En lugar de usar un PHP MVC en toda regla, estoy diseñando uno que se adapte mejor a mis usos. Tengo el marco básico hecho, y he codificado los modelos y controladores que necesitaré para ejecutar mi sitio web.
Ahora me estoy moviendo a las Vistas, y me he encontrado con un pequeño dilema. Mi enfoque está funcionando bien para mí, pero para referencia futura, quiero saber si lo que estoy haciendo es un mal hábito para entrar.
Lo que intento hacer
En mi vista, estoy llamando a un modelo que ejecuta mi sistema de autenticación y solicita el estado de inicio de sesión de un usuario. Luego uso ese booleano para decidir si mostrar ciertos elementos dentro de la vista y dónde colocar otros.
¿Debería diseñar vistas separadas para cada estado de inicio de sesión, o este enfoque es correcto? Sin embargo, si voy a implementar este MVC en el trabajo que estoy haciendo para mis clientes, necesito usar las mejores prácticas.
¡Cualquier consejo sería apreciado!
¿Puedo llamar al modelo desde la Vista?
Sí tu puedes. Siempre que mantenga la separación de preocupaciones entre M, V y C, puede invocar el Modelo (o el Controlador) desde la Vista. La mayoría de los diagramas MVC muestran una conexión bidireccional al menos entre Ver y Modelo. Sin embargo, lo que no quiere hacer es colocar la lógica / código del Modelo (o el controlador) en la Vista y no desea modificar el modelo desde allí.
Por ejemplo, puede tener un widget en su página que agregue los últimos diez titulares de publicaciones de blog de sus blogs favoritos en cada página de su sitio web. Obtendrá los titulares llamando, digamos MyFavFeeds::getLatest(); en tu modelo. ¿Cuáles son tus opciones ahora?
- Podría agregar el código para buscar los titulares en el controlador, pero eso requeriría que lo replique en todas y cada una de las acciones del controlador, lo cual está en contra del principio DRY. Además, la preocupación del controlador es manejar la entrada del usuario para acciones específicas y buscar los titulares en cada llamada probablemente ni siquiera esté relacionado con estas acciones.
- Si su arquitectura lo admite, puede obtener esos datos en algún tipo de gancho preDispatch, es decir, los titulares se cargan e inyectan en la Vista desde un complemento o devolución de llamada. Eso sería DRY, pero un segundo desarrollador podría no estar al tanto de ese complemento y accidentalmente sobrescribir la variable que contiene los titulares de su acción de controlador. Y puede haber casos en los que no desee cargar los titulares, por ejemplo, cuando solo está presentando páginas de confirmación para envíos de formularios, entonces tendría que tener un mecanismo para deshabilitar el complemento. Eso es mucho para considerar.
- Usted coloca la llamada (no el código de)
MyFavFeeds::getLatest()en la plantilla Ver o Diseño o, mejor, un ViewHelper, que encapsula la llamada a su clase de modelo y representa el widget. De esta forma, no tiene que preocuparse por sobrescribir ninguna variable o repetición. Y cuando no necesita los titulares en su vista, simplemente no los incluye.
Sobre su otra pregunta:
En mi vista, estoy llamando a un modelo que ejecuta mi sistema de autenticación y solicita el estado de inicio de sesión de un usuario. Luego uso ese booleano para decidir si mostrar ciertos elementos dentro de la vista y dónde colocar otros.
La autenticación es algo que querrá hacer al principio del flujo de la aplicación, antes de llamar a cualquier acción del controlador. Por lo tanto, no debe ejecutar su sistema de autenticación (completo) en la Vista. La autenticación real no es lógica relacionada con la visualización. Solo solicitar el estado del usuario después de la autenticación, por otro lado, está bien. Por ejemplo, si quiere renderizar un widget mostrando el nombre de usuario y dando un botón de inicio / finalización de sesión, estaría bien hacer algo como
<?php //UserHelper
class UserMenuHelper
{
public function getUserMenu()
{
$link = ''<a href="/user/logout">Logout</a>'';
if(MyAuth::userHasIdentity()) {
$link = sprintf(''<a href="/user/logout">Logout %s</a>'',
MyAuth::getUsername());
}
return $link;
}
}
Si su función de usuario modificó partes más grandes de su GUI, es posible que desee dividir su Vista en bloques parciales e incluirlos en función del estado, en lugar de escribir todo el código HTML en un View Helper.
Si solo busca renderizar una navegación basada en la función del usuario, eche un vistazo a Zend_Navigation y Zend_Acl Zend Framework para ver cómo lo hacen.
Aunque solo sé lo suficiente sobre MVC para meterme en problemas, siempre he vivido por el hecho de que a menos que su vista sea ESTRICTAMENTE la interfaz de usuario, entonces no debería estar allí.
Además, también corrí con la idea de controladores delgados, modelos gordos.
Saliendo de estos, sugiero agregar un método a su modelo de sistema de autenticación que devuelva la vista apropiada para procesar y la pase a la vista.
De acuerdo, realmente trataría de mantener mi Views lo más libre de lógica posible. Si necesita cambiar algo en función de, por ejemplo, el resultado de un método modelo, coloque un controlador que delegue el procesamiento.
Solo asegúrate de seguir la idea básica: haz tus cosas en los modelos, cuéntales a tus modelos qué hacer con tus controladores y también comparte tus puntos de vista con tus controladores.
Puedes, pero no deberías . Excepto por algunos casos extremos (y la bifurcación de su vista basada en el estado de inicio de sesión definitivamente no es un "caso extremo"), es casi siempre una mala idea llamar a un modelo desde una vista.
Lo que probablemente quiera hacer en su situación es pasar el booleano a la vista a través del controlador. De esta forma, si cambia algo sobre el modelo de Usuario, la vista no tiene que saberlo, siempre y cuando el controlador mantenga el mismo comportamiento.