51 messaggi dal 17 maggio 2011
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
11.857 messaggi dal 09 febbraio 2002
Contributi
Ciao,
io mi creo sempre un viewmodel perché così ho tutta la libertà di modellarlo attorno alla view che andrà a presentare i dati.



Finchè di tratta di entità a se con le semplici view CRUD non c'è nessun problema

Ma è raro che una view debba presentare TUTTE le proprietà di un'entità. Oltretutto, l'entità dovrebbe avere al suo interno della logica di business per l'aggiornamento dei dati e non consentire la modifica indiscriminata tramite proprietà con setter pubblico.

O meglio, ci sono delle applicazioni data-driven da realizzare in quattro e quattr'otto che sono poco più di un foglio Excel, in cui potresti effettivamente dare in pasto l'entità alla view.

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. Se realizzi una view secondo il principio della task-based UI, infatti, avrai vari bottoni di aggiornamento. Così puoi catturare meglio l'intento dell'utente. Se invece gli dai un unico mega-form, farai molta più difficoltà a capire che campo ha toccato esattamente o ad autorizzate gli utenti alla modifica di specifiche parti dell'entità.
Ecco un esempio:
https://image.slidesharecdn.com/psidi6-1209718520335063-8/95/patterns-for-distributed-systems-45-638.jpg?cb=1417148172

ciao,
Moreno

Enjoy learning and just keep making
51 messaggi dal 17 maggio 2011
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?
11.857 messaggi dal 09 febbraio 2002
Contributi
Ciao,


Percui la tua tendenza è tenere entity del context POCO e poi creare tanti view model integrando li le logiche di business.

No, la logica dovresti metterla dentro l'entity class. Il viewmodel invece è un semplice DTO che serve solo a trasportare dei valori dai tuoi servizi (il "business layer" dell'applicazione) fino alla view.


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.

Nella view creati un mini form contenente solo le proprietà che devono essere aggiornate. Lato server, grazie al model binding, fai finire quei valori dentro un oggetto adibito allo scopo (questo oggetto è spesso chiamato "command" oppure "editviewmodel" o come vuoi - è lui stesso un DTO). Questo oggetto lo passi a un tuo servizio nel business layer che si occuperà di recuperare l'entità dal database, invocare un suo metodo passandogli i valori per aggiornarla, e poi ripersisterla nel db.


Problema 1 se un campo viene aggiornato da servizi di backend, perdevo aggiornamento.

Per evitarlo usa la concorrenza ottimistica.


Problema 2 se utente modifica html riesce a modificare il dato.

Devi comunque attuare una validazione e un'autorizzazione lato server. Non puoi fidarti di ciò che il client ti manda.


Invece con un model view separato potrei integrare solo i campi di cui necessito veramente e validare senza problemi il model state.

Esatto ma devi comunque verificare lato server che l'utente sia autorizzato a compiere quell'operazione.


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?

Questo sta a te deciderlo. Puoi certamente usare la tecnica che hai descritto.
Oppure puoi anche tenere tutto nella stessa pagina.
Prendi questo esempio: è una task-based UI che contiene più bottoni, ciascuno adibito alla modifica di un particolare aspetto di un'anagrafica.
https://jsfiddle.net/cg7ggmo1/1/

ciao,
Moreno

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.