¿Los modelos de vista en ASP.Net MVC deberían ser todas las cadenas?

Question

He llegado al punto (involuntariamente) de que siento que en algunas partes estoy haciendo demasiado en la vista (.aspx) en sí mismo, demasiado formateo, concatenación, en un lugar, un poco de reemplazo de expresiones regulares.

Estaba empezando a trabajar en una parte nueva y tratando de mejorar mi enfoque ... Entonces me di cuenta por qué no hago todas mis cadenas de modelos de visualización (en/Modelos/en. Proyecto web) o una lista de cuerda en un empuje. Nota: No me estoy refiriendo a mi modelo/dominio, sino específicamente a mi ViewModel.

public class FinanceQuoteView 
{ 
    public string Provider; 
    public string Broker; // rather than Broker == null ? "N/A" : Broker.ToUpperCase(); 
    public string Monthly; // rather than Monthly.ToString("C") 
    public string PaymentTerm; // rather than "1+" + PaymentTerm.ToString(); 
    public string FreeInsurance; // rather than insuranceIncluded ? "Yes" : "No"; 
    public string[] Restrictions; 
} 

Para la presentación Formulario (edición de la adición) que utilizan un modelo de vista separada para alimentar a la acción del controlador (modelo de formulario si se quiere en/Modelos/Formulario). Entonces, FinanceQuoteForm contiene dobles, etc., construidos a través de una carpeta.

¿Qué piensan todos acerca de este enfoque? Está haciendo .ToString ("C") en la asignación de dominio para ver el modelo demasiado?

Answer 1

Su modelo debe producir los datos correctos, luego depende de la vista producir los datos en el formato que requiere. Si creó otra vista en la parte superior del modelo, es posible que desee realizar diferentes manipulaciones de los datos, por lo que sugiero NO devolviéndolos como cadenas del modelo.

Answer 2

Tiendo a inclinarme bastante hacia cadenas para los modelos de vista que diseño. Después de todo, la mayoría de los datos que se muestran en la Vista toman la forma de cadenas. Cada vez que estoy a punto de realizar la manipulación de datos en la Vista (.aspx/.ascx), considero seriamente bajar esa lógica a mi Modelo de Vista para que pueda probarlo en una unidad. Después de todo, Testability es el beneficio major que obtiene de MVC, entonces ¿por qué no usarlo?

En WPF (solo para desviarse brevemente), muchos de los controles comprenden de forma nativa otros tipos de datos (como números, booleanos, etc.), pero en una plataforma ligada intrínsecamente a cadenas como HTML, hace Tengo mucho sentido para mí tratar la mayoría de los resultados como texto.

Todos los datos tienen que pasar de ida y vuelta entre el servidor y el navegador codificados como cadenas de todos modos, tan a menudo, simplemente sería explícito al respecto.

Definitivamente no creo que sea demasiado - sólo pienso lo puede hacer muy poco :)

Answer 3

Sus costuras situación es muy especial y limitada de una manera: Su modelo de vista es ya sea para la edición o visualización . La mayoría de las vistas hacen ambas cosas: tienen muchas cosas de visualización y algunas cosas de edición. Digamos esta página:

Mostrar pregunta, respuestas y notas. Editar: respuesta.

No me gustaría distinguir el 2. Terminaría en la duplicación de una gran cantidad de campos de visualización.

Preferiría tener una vista con posiblemente 2 propiedades: una para la pantalla y otra para el valor del formulario.

Answer 4

De acuerdo, en su mayoría. Para los formularios de edición tradicionales, prefiero tener modelos separados para el 'modelo de publicación' (pasado al controlador) y para la vista/edición del 'modelo de vista' (pasado a la vista).

Las propiedades del modelo de publicación son todas cadenas. Esto me permite determinar si un campo se incluyó en la publicación, algunos no, esto es muy importante para mi aplicación.

El modelo de publicación alimenta mi acción de controlador que luego determina qué comando (s) ejecutar, si corresponde.

Desde allí, si la acción del controlador da como resultado la visualización de la página de visualización/edición, entonces construyo el modelo de vista en consecuencia y se lo proporciono a la vista.

Por lo tanto, puedo hacer que las propiedades de mi modelo de vista sean del tipo que quiera. No tienen que coincidir con los tipos del modelo de publicación.

Super clean, y me da un control total sobre todo.