Cuándo usar vistas fuertemente tipadas?

Question

Estoy trabajando en una aplicación MVC y me pregunto en qué situación es mejor utilizar una vista fuertemente tipada y cuando no ... Supongo que esto es más una pregunta de mejores prácticas. Estoy haciendo una aplicación de comercio electrónico y hay una tabla para pedidos, productos, etc. La parte en la que estaba trabajando que me trajo a esta pregunta fue que agregué una nueva página de producto para que los administradores pusieran más artículos en la tienda. Cualquier consejo sobre cuándo saber utilizar una vista fuertemente tipada será de gran ayuda.

Ya he buscado preguntas relacionadas y nada apareció en las primeras 3 páginas, pero si conoce una publicación, por favor diríjase a mí.

Gracias.

Answer 1

Uso las vistas fuertemente tipadas siempre que puedo para poder alejarme de todas las versiones de varios bits de ViewData dentro de la vista.

Creo mis propias vistas fuertemente tipadas cada vez que necesito información de más de una fuente para la vista.

Por ejemplo, en mi comprobación, requiero un pedido pero también las pretensiones del usuario para la visualización de precios; así que creé CheckoutViewModel, que tiene una propiedad Order and PriceDisplay.

Espero que ayude,

Dan

Answer 2

Una vista fuertemente tipada se utiliza mejor cuando modifica una instancia de ese tipo en la vista.

Por ejemplo, al editar o crear un Producto en una vista, definitivamente sería aconsejable tener una vista fuertemente tipada para la clase de producto.

Si solo está visualizando texto o imágenes sin tener realmente una conexión con algo en las capas de base de datos subyacentes, probablemente sería más fácil pasar sin una vista fuertemente tipada.

Todo esto vendrá de forma bastante natural a medida que trabaje más con MVC en mi experiencia.

Answer 3

Cada vez que necesite mostrar datos (en cualquier objeto o conjunto de objetos en particular) en la vista, use una vista fuertemente tipada.

Si su visión es meramente informativa, es posible que pueda utilizar el ModelState para pasar pequeños trozos de información (por ejemplo: páginas Éxito/Error, no autorizados Mensajes, etc.) y

En mis aplicaciones, I tener CADA vista fuertemente tipada, para que pueda pasar fácilmente la información de inicio de sesión de usuario a la Página maestra. Es decir, todas mis vistas están fuertemente tipadas, modeladas y restringidas a una clase base que contiene la Configuración del sitio y la información de Inicio de sesión del usuario.

Debido a eso, puedo hacer esto:

public class MyBaseMasterPage : ViewMasterPage<MyBaseModel> 
{ 
    public string CurrentTheme 
    { 
     get 
     { 
      if (this.Model.CurrentUser != null) 
       return this.Model.CurrentUser.Theme; 

      else return this.Model.Config.DefaultTheme; 
     } 
    } 

    public User CurrentUser { get { return this.Model.CurrentUser; } } 

    public ConfigurationRepository Config { get { return this.Model.Config; } } 
} 

Tenga en cuenta que, desde la página maestra es temático basado en sólo lo que se rellena en el modelo, el propio Vista nunca va a desencadenar un golpe a la base de datos /cache.

MyBaseModel está configurado de este modo:

public class MyBaseModel 
{ 
    private MyBaseModel() { } 

    public MyBaseModel(MyBaseController controller) 
    { 
     this.CurrentUser = controller.CurrentUser; 
     this.Config = controller.Config; 
    } 

    public User CurrentUser { get; private set; } 

    public ConfigurationRepository Config { get; private set; } 
} 

El constructor privado obliga a todas las subclases de mi modelo para inicializar el modelo con el controlador cómoda de fuente.

La base de controlador clase saca al usuario de la sesión y la configuración de caché.

De esta manera, no importa qué, todas mis vistas tienen acceso a los datos de usuario y configuración, sin generar un golpe en la base de datos.

Ahora, en MyBaseController:

public class LanLordzBaseController : Controller 
{ 
    [Obsolete] 
    protected new ViewResult View(string viewName, object model) 
    { 
     if (model == null) 
     { 
      throw new ArgumentNullException("model"); 
     } 

     if (!(model is MyBaseModel)) 
     { 
      throw new ArgumentException("The model you passed is not a valid model.", "model"); 
     } 

     return base.View(viewName, model); 
    } 

    protected ViewResult View(string viewName, MyBaseModelmodel) 
    { 
     if (model == null) 
     { 
      throw new ArgumentNullException("model"); 
     } 

     return base.View(viewName, (object)model); 
    } 

    public ConfigurationRepository Config { get { ... } } 

    public User CurrentUser { get { ... } } 
} 

Esto me ayudó a encontrar todos mis controladores que regresaban puntos de vista que no se heredan de la clase base adecuada.

Answer 4

Aunque estoy repitiendo lo que otros han dicho elocuentemente Creo que hay un punto más para subir. La Vista es parte del concepto de Modelo, Vista y Controlador, y como tal existe para presentar el Modelo de forma visual al usuario. Dado que, en esencia, es una representación del Modelo, tiene sentido que esté fuertemente tipado.

Solo uso ModelState o TempState para pasar pequeños datos, como mensajes de resultados de actividades como agregar, eliminar, etc. Siempre que me resulta tentador usar State para pasar colecciones que no están relacionadas con View-type, entonces Refactorizo ​​esa funcionalidad en una vista parcial y la presento a través de una acción de controlador separada.

En mi código, los tipos relacionados generalmente se referencian jerárquicamente desde el tipo de base al que la vista está fuertemente tipada, por lo que se puede acceder a ellos desde la Vista cuando sea necesario.

Answer 5

Si hay datos involucrados, debe haber una vista fuertemente tipada. Período.

Answer 6

Siempre. Yo iría más lejos y usaría controles fuertemente tipados y acciones de HtmlHelper también. La mayoría están disponibles en la biblioteca MvcContrib.