Uso corretto del modello in asp mvc

La tua confusione è comprensibile. Diversi modelli MVC hanno approcci diversi quando si tratta di modelli: alcuni incoraggiano modelli leggeri, mentre altri accolgono modelli che contengono molte informazioni.

In ASP.NET MVC, la pratica comune che osservo in molti progetti è la seguente:

Logica aziendale:

• I modelli non contengono la logica aziendale. In altre parole, non eseguono nulla che coinvolga le regole aziendali: questo è il compito di un controllore e le classi utilizzate dal controller.

• I modelli non contengono logica elementare che viene solitamente eseguita da una vista. Ad esempio, se la pagina dovesse visualizzare una data in un formato di facile utilizzo, come "15 novembre ^th , 2013", il controller utilizzerà solo DateTime oggetto che rimarrà così com'è il modello. È la visualizzazione che sarà responsabile della conversione da DateTime a un formato specifico (eventualmente utilizzando la localizzazione).

Accesso al database:

• I modelli non accedono direttamente al database. Questo potrebbe essere ovvio per te, ma il predecessore-ASP.NET, spesso aveva query SQL all'interno dei template , qualcosa che sarebbe considerato pazzo dalla maggior parte degli sviluppatori oggi.

• I modelli possono contenere pigri IEnumerable<T> elementi che portano al database; né il modello né la vista definiscono il modo in cui i dati vengono caricati, ma il caricamento stesso viene posticipato fino a quando non viene visualizzata la vista, anziché essere eseguita dal controller.

Dati:

Resta ovviamente il dato stesso, ovvero i dati caricati dal controller e trasferiti a una vista attraverso un modello. In un modello, generalmente si trovano tutti i dati necessari per generare la pagina, ad eccezione del contenuto statico. Ad esempio, su una pagina Web che visualizza i prodotti, il modello potrebbe contenere:

• L'elenco di prodotti (in forma di pigro IEnumerable<T> ),
• Le informazioni sull'utente, se l'utente è autenticato,
• Il carrello,

e non contengono elementi come:

• Il logotipo del sito web,
• Il menu del sito,
• Il piè di pagina con avviso sul copyright,

poiché possono risiedere nella vista.

Modello, ViewData, ViewBag e TempData

Dal rilascio del DLR, non è raro vedere i dati in luoghi diversi dal modello, con conseguente maggiore confusione. Anche il progetto dimostrativo ASP.NET MVC sposta molte informazioni dal modello in ViewBag.

La scelta qui è fondamentalmente uguale alla scelta tra digitazione statica e digitazione dinamica, con una differenza.

• Ciò che è lo stesso è che puoi se vuoi spostare tutto su ViewBag ed evitare l'uso di un modello, o tenere tutto nel modello ed evitare l'uso di ViewBag: nel caso di un modello, hai il vantaggio della digitazione statica , che spesso significa codice più rigido con bug trovati in fase di compilazione invece che in fase di esecuzione.

  Ad esempio, se si prevede una data nel modello e la vista sta estraendo informazioni da questa data (ad esempio la visualizzazione in formato leggibile), il controller non può passare una stringa. Visual Studio ti avviserà sottolineando la stringa e, se proverai a compilare, vedrai un errore.

  Se, invece, la data è nel ViewBag e invece di un oggetto DateTime , metti una stringa, Visual Studio andrà bene e il compilatore non ti dirà nulla. Dovrai attendere finché non esegui la pagina per vedere se qualcosa è andato storto.

• La differenza, d'altra parte, è che le visualizzazioni di ASP.NET MVC hanno uno status speciale di cittadini di seconda classe. Dal momento che, per impostazione predefinita, non sono compilati, è molto facile commettere errori nelle visualizzazioni stesse (ad esempio aspettandosi un DateTime mentre il modello indica che contiene string ).

  Ciò significa che non c'è nulla di male nel fare molto affidamento sugli aspetti dinamici di ViewBag in ASP.NET MVC. Se sai che il tuo modello e la tua vista cambieranno molto, vai con il ViewBag dinamico. Se sai che il modello è ben definito e non soggetto a modifiche a meno che i requisiti non cambino, il modello reale, tipizzato staticamente, sarebbe probabilmente una scelta migliore.

Un altro aspetto che dovrebbe essere notato è la prestazione. Se stai realizzando un'applicazione web su larga scala, dovresti confrontare in modo definitivo le prestazioni dei modelli con tipizzazione statica con le prestazioni del ViewBag dinamico. Ricordo che i miei benchmark per un progetto che non aveva nulla a che fare con ASP.NET MVC dimostrava che il passaggio tra tipi statici e dynamic non ha praticamente alcuna differenza in termini di prestazioni, ma comunque assicurati di fare i benchmark effettivi.