Antes de emitir en un modelo de vista deben tener el formato:MVC - ¿Quién formatea el modelo?
¿Quién realiza todo este formato - Controlador o Vista?
¿Tengo razón en que todo el formateo se lleva a cabo por el controlador que crea el llamado ViewModel que contiene solo valores formateados y envía este ViewModel a la vista?
¡Gracias de antemano!
Eric Petroelje tiene razón, pero yo crearía una clase (s) auxiliar para obtener contenido/fechas localizadas, etc., porque la localización no siempre está en las vistas, p. enviando correos electrónicos con contenido localizado. Tendría algo como LocalisationHelper.GetString ("MyKey"), o LocalisationHelper.GetDate (Date.Now), donde LocalisationHelper conoce la ubicación actual de los usuarios (tal vez de Session).
continuación, utilizar este directamente en los puntos de vista que sea posible:
<%= Html.Encode(LocalisationHelper.GetDate(Date.Now)) %>
Todo eso parece una lógica de capa de presentación, así que personalmente creo que debería ir en la vista.
ETA:
yo no estaría a favor de tener la vista de llamadas objetos de la capa de servicios en el sentido general, pero para la localización creo que tiene sentido.
Por ejemplo, supongamos que tiene un montón de texto estático en sus páginas que ha tokenizado y almacenado en una base de datos en varios formularios localizados. No creo que tenga sentido que el controlador tenga que buscar y colocar todos los tokens de texto en el modelo. Aunque una búsqueda de token de texto es técnicamente una operación de "capa de servicio", todavía creo que tiene sentido que la vista llame a ese servicio directamente a través de alguna clase de utilidad en lugar de hacer que el controlador lo haga.
Entonces deberíamos dar vista con los datos adicionales como la "configuración regional del usuario" y la vista debe saber cómo traduce cadenas según la configuración regional y así sucesivamente. ¿No es demasiado para una vista? –
@Andrey - Creo que la respuesta de JonoW resume cómo manejar el problema de localización de cadenas bastante bien. –
Por favor, eche un vistazo a mi comentario. JonoW ofrece un modelo fuertemente acoplado donde tanto el controlador como la vista usan el mismo servicio. No veo la diferencia entre el controlador y la vista, entonces. –
La vista es responsable de esta no el controlador.
Para explicar lo que necesito para elaborar un poco acerca de lo que la "vista" es:
En ambos patrones de interfaz gráfica de usuario MVC basadas en la Web y tradicionales, el View es responsable de la representación exterior de cualesquiera partes del modelo que se muestran. Si eso significa "formatear" datos del modelo, entonces que así sea.
El controlador no debe formatear los datos, porque el controlador es responsable de hacer las cosas al modelo en función de los eventos/comandos provenientes del mundo exterior. El controlador no tiene nada que ver con la renderización de la salida.
Ejemplo:
Quiero mostrar un carro de compras con varias líneas de pedido:
<%= message_renderer.text(:insufficient_funds) %>. En este caso, "message_renderer" y el archivo de plantilla son ambos parte de la vista.Las vistas no son necesariamente solo plantillas basadas en web. En algunos frameworks basados en Java, por ejemplo, ponemos "view objects" en una plantilla de velocidad. Esos objetos de vista están vinculados de nuevo a objetos en el modelo, pero también realizan un comportamiento de representación y formato bajo demanda. Esos son parte de la vista, aunque no son solo una plantilla.
Es un poco confuso con marcos como ruby on rails y groovy en griales, donde llaman a la plantilla la "vista", cuando una vista es realmente más que una plantilla. Tradicionalmente (en Smalltalk MVC y en Java's Swing) las vistas son solo códigos que pueden realizar formateos, renderizaciones y cualquier otro comportamiento relacionado con la visualización.
¡Gracias! Pero la localización aún me causa problemas. Su message_renderer se parece al servicio de dominio con estado que conoce acerca de la sesión del usuario (vea también mis comentarios a continuación). ¿Es normal llamar a servicios desde una vista? –
No es un servicio. Es un objeto de vista, y tendrá que conectarse a los objetos del modelo para obtener el mensaje localizado correcto, aunque no se puede ver desde el fragmento que utilicé. Sospecho mucho de los servicios porque son solo fragmentos de funcionalidades globalmente visibles: ¡nada que ver con MVC u otro código orientado a objetos! – daf
Bueno, dice que su vista se conecta al modelo para obtener la configuración regional del usuario. Si es así, ¿por qué no puede esa Vista también "conectarse al Modelo" para obtener los objetos para ver de esta manera - "repository.getBooks();"? ¿No ves nada extraño con este código? Parece que el Controlador ya no es necesario ya que su Vista puede "conectarse al Modelo". Creo que hay un error en alguna parte de tus sugerencias. –
patrones de diseño 101.
Modelo es para almacenar datos (por lo general en bases de datos).
Ver es para presentar los datos (no manipulándola).
controlador es para manipular el modelo y de paso, que a la vista (la elección de la configuración regional correcta, por ejemplo, iría aquí).
MVC no significa necesariamente que tiene 3 clases distintas, sino 3 componentes o capas. Estos son abstractos y no necesariamente tienen que estar vinculados a una clase física. Dentro de tu capa de Controlador, puede consistir en cualquier cantidad de clases auxiliares o lo que sea.
Estoy de acuerdo con parte de lo que está diciendo cartoonfox, todo está entrelazado. Por ejemplo, si desarrolla una vista para un carro de compras, pero el modelo contiene información de cumpleaños, entonces no va a funcionar. Es simplemente un patrón de diseño para ayudar a eliminar la duplicación de esfuerzos. Cuando tiene menos variables y menos ruido, es mucho más fácil enfocarse en lo que se necesita hacer y entenderlo muy bien.
Tuve una discusión con nuestro equipo sobre el uso de anotaciones para representar formularios en una página web. Estas anotaciones se colocaron en el modelo o clase de entidad.A menudo trabajará directamente con clases de entidad, por lo que elimina bastante sobrecarga y duplicación de esfuerzo si coloca aquí sus anotaciones. Debido a que sus anotaciones se colocan directamente en la clase de modelo, no puede terminar con una vista de información de cumpleaños, simplemente no es posible. Además, siguiendo los patrones, eliminas la basura que no agrega valor al resultado final. Simplemente escribe la lógica de negocios y prácticamente nada más.
Aunque las anotaciones pertenecían a la misma clase que la capa del modelo, la capa de presentación o vista consistía en las anotaciones y las clases auxiliares. No necesita necesariamente ser clases o límites distintos.
Otro ejemplo sería. He trabajado en algunas "aplicaciones" web PHP en el pasado. Utilizo aplicaciones porque eran un bloque monolítico de código, más o menos un único método principal con toda la lógica allí (que difícilmente es una aplicación funcional).
Si no abstrae el código en funciones y simplemente utiliza un único método, terminará con mucha duplicación de esfuerzo. Si trataras de entender ese bloque de código monolítico, estarías en un montón de problemas (como yo, era difícil saber qué estaba pasando, luego encontraría un bloque de código similar en otro lugar y quedaría estupefacto por qué pocas cosas se modificaron como estaban).
Se puede hacer de la manera que desee, pero los patrones de diseño como MVC lo ayudan a simplificar lo que escribe para que funcione y también a que se adapte más fácilmente a la solución. Otro patrón o enfoque de diseño popular es dividir y conquistar.
para responder a sus preguntas originales:
En Java, los datos localizados se llevaría a cabo de forma transparente por la aplicación. Por ejemplo, si desea soporte de locales Inglés de EE.UU., debe crear un archivo de propiedades:
messages_en-US.properties
y luego colocar todo el contenido de EE.UU. Inglés allí. Dependiendo de la cantidad de contenido que pueda ser, es posible que desee utilizar un enfoque diferente.
Para mi aplicación tengo páginas enteras en un idioma diferente, así que lo que hago es esto. Mi controlador determina la configuración regional del cliente o la mejor coincidencia. Luego elige qué vista mostrar y pasa el modelo (datos) a la vista.
Si necesita un formato dinámico para su fecha/hora, entonces su controlador es responsable de determinar cuál será utilizado. Entonces, su vista es responsable de usar ese convertidor para formatear el valor.
Estoy utilizando JBoss Seam por lo que el patrón de diseño MVC todavía se utiliza, pero de forma más abstracta. No tengo 'controladores' reales, sino un interceptor que es responsable de manejar una pieza específica de funcionalidad (determinar la configuración regional del cliente y luego otra para su preferencia de fecha/hora). Mis controladores que serían el equivalente de un Controlador de Primavera son componentes de acción responsables de manejar las acciones de la página.
Walter
Eso parece romper el concepto de MVC ya que su vista realmente usa el "servicio de localización", es decir, se comporta como un controlador. –
LocalisationHelper no es un servicio, sería simplemente un formateador para hacer que su código de vista sea más nítido. Simplemente formatea los datos que su Controlador le está dando a su Vista. – JonoW
@JonoW No puedo estar de acuerdo contigo, porque LocalisationHelper conoce la sesión del usuario. Significa que es con estado, así que no es solo un ayudante estático sino un servicio real. Si no fuera así, debe proporcionarle el parámetro Locale. –