Ciao a tutti,

Volevo chiedervi un consiglio, in quanto io mi ritengo un mago a trovare soluzioni funzionali e radicarmi in ciò a discapito dello standard o della buona norma di programmazione.

Nello specifico mi riferisco a come andate a gestire il model per le view.
Finchè di tratta di entità a se con le semplici view CRUD non c'è nessun problema chiaramente, il model è semplice la view avrà quel model e avrò tutte le comodità di data annotation, model state ecc ecc.

Ma per view composite (perdonate magari la poca correttezza dei termini) partendo dalla più semplice, ovvero la index con filtri, fino ad arrivare a view più complesse che integrano 1 o più model come la gestite?

La citazione prima di ritenermi mago è stata per la scoperta della ViewData, in pratica mi pare fantastico tenermi il model più complesso come model della view e poi tutto il resto buttarlo nella viewdata.

MVC non permette di avere una view con due model (Correggetemi se sbaglio), ma eventualmente creare un model wrapper che contiene al suo interno proprietà che corrispondono ai model della mia applicazione.

Altra soluzione che ho visto, è come ad esempio microsoft gestisce il model per identity, in pratica per ogni metodo controller crea un model specifico (in questo caso si tratta sempre delle proprietà di identity e non di più model insieme) presumo anche per sicurezza, la view potrà accedere solo a specifiche proprietà, oltre che per gestire tutte quelle situazioni dove i required delle proprietà potrebbero variare in base al contesto.

Insomma voi che linee guida tenete in generale.

Grazie a tutti per i consigli

Certo mi è chiaro.
Percui la tua tendenza è tenere entity del context POCO e poi creare tanti view model integrando li le logiche di business.
Infatti io, cercando di tenere le entity POCO la logica la creavo nel metodo del controller (o se proprio creavo un nuovo metodo).

E' vero a volte mi sono trovato in difficoltà in particolare per le update, quando avevo la necessità di aggiornare solo alcune proprietà della entity.
Per validare il model state io portato tutto in view con campi hidden e poi facevo il post.
Problema 1 se un campo viene aggiornato da servizi di backend, perdevo aggiornamento.
Problema 2 se utente modifica html riesce a modificare il dato.
Invece con un model view separato potrei integrare solo i campi di cui necessito veramente e validare senza problemi il model state.

Per applicazioni un pelo più complesse, vale la pena creare un viewmodel per la visualizzazione dei dati e altri n per ogni operazione di aggiornamento esposta dalla pagina

Quando parli di questo, nello specifico mi immagino tante partial view con il rispettivo modelview esposte magari in dialog displayed da chiamata asincrona, immagine corretta?