Quando utilizzare le viste fortemente tipizzate?

Question

Sto lavorando su un'app MVC e mi chiedo in quale situazione è meglio usare una vista fortemente tipizzata e quando no ... Immagino che questa sia più una questione di buone pratiche. Sto creando un'app di e-commerce e c'è un tavolo per ordini, prodotti, ecc. La parte su cui stavo lavorando mi ha portato a questa domanda era la mia aggiunta di una nuova pagina di prodotto per gli amministratori per inserire più articoli in negozio. quando sapere usare la visualizzazione fortemente tipizzata sarà di grande aiuto.

Ho già cercato domande correlate e non è uscito nulla nelle prime 3 pagine o giù di lì, ma se si conosce un post, si prega di indirizzarmi.

Grazie.

Answer 1

Uso le viste fortemente digitate quando posso, in modo da poter uscire da tutti i cast di vari bit di ViewData all'interno della visualizzazione.

Creo le mie proprie viste fortemente digitate ogni volta che ho bisogno di informazioni da più di una fonte per la vista.

Ad esempio nel mio Checkout, ho bisogno di un ordine ma anche delle preferenze dell'utente per la visualizzazione del prezzo; così ho creato CheckoutViewModel che ha una proprietà Order e PriceDisplay.

Speranza che aiuta,

Dan

Answer 2

Una vista fortemente tipizzata viene utilizzata al meglio quando si modifica un'istanza di quel tipo nella vista.

Per esempio quando si modifica o creare un prodotto in una vista sarebbe sicuramente adviceable di avere una visione fortemente tipizzato per la classe di prodotto.

Se si visualizzano solo testo o immagini senza avere una connessione a nulla nei databaselayers sottostanti probabilmente sarebbe più facile andare senza una visione fortemente tipizzato.

Questo avverrà in modo del tutto naturale, poiché nella mia esperienza lavorerai di più con MVC.

Answer 3

Ogni volta che è necessario mostrare i dati (su qualsiasi oggetto o raccolta di oggetti) sulla vista, utilizzare una vista fortemente tipizzata.

Se il vostro punto di vista è puramente informativo, si può essere in grado di utilizzare il ModelState per passare piccole quantità di informazioni (ad esempio: pagine Successo/Errore, non autorizzati Messaggi, e così via)

Nelle mie applicazioni, I avere OGNI visualizzazione fortemente scritta, in modo che possa facilmente passare le informazioni di accesso dell'utente alla Pagina Master. Cioè, tutti i miei punti di vista sono fortemente tipizzati, su modelli e vincolata ad una classe di base che contiene la configurazione del sito e le informazioni Login utente.

A causa di ciò, posso fare questo:

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; } } 
} 

Nota che, dal momento che la pagina master è a tema sulla base di solo ciò che è popolato nel modello, la vista in sé non sarà mai innescare un colpo al database/cache.

MyBaseModel è configurato in questo 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; } 
} 

Il costruttore privato costringe tutte le sottoclassi di mio modello per inizializzare il modello con il controller laghetti L'alimento.

La classe di base del controller estrae l'utente dalla sessione e dalla cache di Config.

In questo modo, non importa cosa, tutti i miei punti di vista hanno accesso ai dati degli utenti e di configurazione, senza mai generare un colpo al DB.

Ora, in 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 { ... } } 
} 

Questo mi ha aiutato a trovare tutti i miei controller che tornavano viste che non sono stati ereditati dalla classe base appropriata.

Answer 4

Anche se sto a ripetere ciò che altri hanno eloquentemente dichiarato Penso che ci sia un punto in più per alzare. La vista è parte del concetto di modello, vista, controllore e come tale è lì per presentare il modello in modo visivo all'utente. Dato che è, in sostanza, una rappresentazione del modello, ha senso che sia fortemente tipizzato.

Uso sempre ModelState o TempState per il trasferimento di piccole porzioni di dati, come messaggi di esito da attività come aggiungere, eliminare, ecc. Ogni volta che trovo tentato di utilizzare State per passare raccolte non correlate al tipo View, quindi Ricalcolo questa funzionalità in una vista parziale e la presento attraverso un'azione separata del controllore.

Nel mio codice i tipi correlati sono generalmente referenziati gerarchicamente dal tipo di base a cui la vista è fortemente tipizzata, e quindi sono accessibili all'interno della vista ove necessario.

Answer 5

Se ci sono dati coinvolti, ci dovrebbe essere una vista fortemente tipizzata. Periodo.

Answer 6

Sempre. Vorrei andare oltre e utilizzare anche comandi fortemente tipizzati e azioni HtmlHelper. La maggior parte sono disponibili nella libreria MvcContrib.