La convalida di ASP.Net MVC 2 richiede un po 'più di riflessione in termini di schemi e utilizzo?

Question

Ecco la disposizione della terra. Come la maggior parte delle persone, ho il mio oggetto dominio e ho i miei modelli di vista. Mi piace l'idea di utilizzare i modelli di visualizzazione, in quanto consente di creare modelli specifici per un determinato contesto di visualizzazione, senza dover modificare i miei oggetti di business.

Il problema che ho è con la convalida di livello tipo definito sul mio oggetto dominio e ottenere tali norme per il cliente. In questo caso, diciamo che sto usando le annotazioni di dati per descrivere le regole di convalida, quando sposto i dati dall'oggetto dominio al modello di vista, il modello di vista non sa più quale validazione deve ottenere l'interfaccia per eseguire (perché la convalida è definito di nuovo sull'oggetto dominio).

Con MVC 2 si può ottenere per eseguire automaticamente validazione lato client/server, in base alle regole di convalida dell'oggetto corrente. Ma poiché le regole di convalida sono definite sull'oggetto dominio e non sul modello di visualizzazione, dovrei duplicare le regole di convalida sul modello di visualizzazione per farlo funzionare.

Come gli altri si occupano di questo tipo di problema? Il mio pensiero è che oltre a mappare i dati dall'oggetto dominio al modello di visualizzazione, dobbiamo anche mappare le regole di convalida, ma in realtà non ho visto gli altri parlare di questo problema ... Brad Wilson ha recentemente parlato di questo problema alla fine, ma non ha davvero affrontato la duplicazione delle regole sull'oggetto dominio e sui modelli di visualizzazione ... quali sono i tuoi pensieri?

Acclamazioni Anthony

Answer 1

Gli attributi DataAnnotation riguardano la convalida dell'input e il feedback dell'interfaccia utente all'utente finale. Questo è davvero il loro solo uso previsto. Io uso diverse strategie di validazione per gli oggetti dell'interfaccia utente e gli oggetti business, quindi gli attributi di convalida DA finiscono solo sui modelli mostrati all'utente.

Answer 2

Questo potrebbe non essere appropriato, ma cosa succede se si appena spostato le regole di validazione/annotazioni dai modelli ai tuoi ViewModels? In alcuni dei progetti in cui sono stato, abbiamo scelto di impedire alla View di accedere a qualsiasi cosa che non fosse l'informazione esposta attraverso il corrispondente ViewModel. Dal momento che tutta l'interazione dei dati verrebbe eseguita tramite ViewModel, non sarebbe necessario avere la convalida sugli oggetti del modello.

Il contatore di questo argomento è che è possibile duplicare facilmente determinate regole di convalida, dal momento che diversi ViewModel potrebbero interfacciarsi con gli stessi Modelli. In questo caso, potrebbe essere opportuno dichiarare semplicemente il modello come una proprietà esposta sul ViewModel. Per i postback, potevano accettare un modello come parametro, consentendo all'infrastruttura ModelBinder di gestire la richiesta. In questo caso, se ModelState.IsValid è falso, puoi semplicemente riassegnare la proprietà a ViewModel prima di rivisualizzare la vista.

lo consiglio muovere le annotazioni ai tuoi ViewModel. Ha senso dal momento che molte viste sono a) il risultato della composizione di diversi modelli o b) un sottoinsieme di dati del modello.

Answer 3

Probabilmente non dovremmo usare visualizzare i modelli a tutti? E definire le regole di convalida sulle entità del livello del modello.

Answer 4

Ho preso in considerazione anche questo per un po 'di tempo. Capisco perfettamente la risposta di Brad. Tuttavia, supponiamo di voler utilizzare un altro framework di validazione adatto per l'annotazione di entità di dominio e modelli di visualizzazione.

L'unica soluzione che riesco a trovare su carta che funzioni ancora con gli attributi sarebbe quella di creare un altro attributo che "punti" alla proprietà di un'entità di dominio che si sta specchiando nel proprio modello di vista.Ecco un esempio:

// In UI as a view model. 
public class UserRegistration { 
    [ValidationDependency<Person>(x => x.FirstName)] 
    public string FirstName { get; set; } 

    [ValidationDependency<Person>(x => x.LastName)] 
    public string LastName { get; set; } 

    [ValidationDependency<Membership>(x => x.Username)] 
    public string Username { get; set; } 

    [ValidationDependency<Membership>(x => x.Password)] 
    public string Password { get; set; } 
} 

Un quadro come xVal potrebbe essere esteso per gestire questo nuovo attributo ed eseguire la convalida gli attributi della proprietà di classe di dipendenza, ma con il valore della proprietà la visualizzazione del modello. Non ho avuto il tempo di approfondire questo aspetto.

Qualche idea?

Answer 5

Si scopre che AutoMapper potrebbe essere in grado di farlo automaticamente per noi, il che è il migliore dei casi.

AutoMapper-utenti: trasferisce gli attributi di convalida a viewmodel?
http://groups.google.com/group/automapper-users/browse_thread/thread/efa1d551e498311c/db4e7f6c93a77302?lnk=gst&q=validation#db4e7f6c93a77302

Non ho ancora avuto modo di provare le soluzioni proposte, ma intendo farlo a breve.

(Cross ha postato questo sulla mia domanda (dupe) pure).