2010-10-25 17 views
7

Sono nuovo in MVC/MVP e sto imparando creando un'applicazione Winform.in MVC/MVP

Ho creato in qualche modo Modelli, Presentatori e Viste ... Ora dove si adattano le mie convalide.

Penso che la convalida del tipo di dati iniziale (come solo i numeri nel campo Età), dovrebbe essere eseguita alla vista. Mentre le altre convalide (come se l'età è entro 200) dovrebbero essere fatte per modello.

Per quanto riguarda la convalida tipo di dati, la mia opinione espone i valori come proprietà

public int? Age 
{ 
    get 
    { 
     int val; 
     if (Int32.TryParse(TbxAge.Text, out val)) 
     { 
      return val; 
     } 
     return null; 
    } 
    set 
    { 
     TbxAge.Text = value; 
    } 
} 

posso eseguire la convalida separatamente, ma come faccio a informare presentatore che la convalida è ancora in sospeso, quando si tenta di accedere alla proprietà Age?. In particolare quando il campo è facoltativo.

È buona norma lanciare un'eccezione di validationpending, ma il presentatore deve prenderla in ogni punto.

La mia comprensione è corretta o mi manca qualcosa.

Aggiornamento (per motivi di chiarezza): In questo semplice caso in cui il campo età è facoltativo, cosa devo fare quando l'utente ha digitato il suo nome anziché un numero. Non posso passare nulla perché significherebbe che il campo è stato lasciato vuoto dall'utente. Quindi, come informo il relatore che sono stati immessi dati non validi ...

risposta

1

Provenendo dal lato MVP (credo sia più appropriato per WinForms) la risposta alla tua domanda è discutibile. Tuttavia, la chiave per la mia comprensione è che in qualsiasi momento dovresti essere in grado di cambiare la tua vista. Cioè, dovrei essere in grado di fornire una nuova vista WinForms per visualizzare la tua applicazione o collegarla ad un front-end ASP.NET MVC.

Una volta capito questo, la convalida diventa aparant. L'applicazione stessa (la logica aziendale) dovrebbe generare eccezioni, gestire gli errori e così via. La logica dell'interfaccia utente dovrebbe essere stupida. In altre parole, per una vista WinForms è necessario assicurarsi che il campo non sia vuoto o così via. Molte proprietà per i controlli consentono questo: il pannello delle proprietà di Visual Studio. La convalida del codice nella GUI per i tipi di eccezioni di lancio è un grande no no. Se dovessi avere la convalida sia sulla vista che sul modello, dovresti duplicare il codice: tutto ciò che ti serve è una semplice convalida, come ad esempio il fatto che i controlli non siano vuoti. Lascia che l'applicazione stessa esegua la convalida effettiva.

Immaginate se ho cambiato la vista su un front-end ASP.NET MVC. Non avrei detto controlli e quindi sarebbe stata necessaria una qualche forma di scripting lato client. Il punto che sto facendo è che l'unico codice che dovresti scrivere è per le viste, cioè non provare a generalizzare la convalida dell'interfaccia utente attraverso le visualizzazioni, in quanto vanificherà lo scopo di separare le tue preoccupazioni.

L'applicazione principale dovrebbe avere tutta la logica al suo interno.La logica di visualizzazione specalizzata (proprietà WinForms, Javascript ecc.) Dovrebbe essere univoca per visualizzazione. A mio avviso, avere proprietà e interfacce che ciascuna vista deve validare è errata.

+0

Dovrei aggiungere, ciò che stai tentando di fare è possibile, ma è sbagliato. Tuttavia, se si è bloccati su questo approccio, è necessario utilizzare gli eventi per proporre errori di convalida nell'app. Utilizzando l'approccio "stupido" disaccoppiato che ho citato, nel complesso viene fornita un'app semplificata. – Finglas

+0

Ok .. Se stai dicendo che dovrei fare la validazione Datatype in Presenter ... Allora le mie viste dovrebbero esporre tutti i valori come proprietà stringa, che potrebbero essere letti e convalidati dal controller? –

+0

Non tutti come stringhe. Usa i tipi primitivi per cominciare. Prendi il tuo esempio di età. Un int è un int se non il suo WinForms o ASP.NET MVC. Sono entrambi C#. Puoi sempre considerare questi primitivi in ​​classi di valore personalizzate come PersonalDetails (in cui l'età verrebbe memorizzata). Queste classi di valore sarebbero quindi utilizzate come "ViewModel". Quello che non vuoi fare con il pattern MVP/MVC sono tipi di ritorno specifici per la tua vista. Gli stream HTML di E.g non funzionerebbero in un'app WinForms, tuttavia una stringa/tipo personalizzato che rappresenta un frammento di testo sarebbe universale. – Finglas

-1

Credo che la convalida della vista sia rilevante solo in javascript poiché la vista non esegue alcun codice su post, solo il controller lo fa.

Ma non mi sarei mai nemmeno fidato della convalida di javascript in quanto un utente malintenzionato potrebbe aggirarlo o un utente ignorante potrebbe aver disabilitato JS in modo da ripetere qualsiasi convalida JS nel codice serveride nel controller.

La vista potrebbe avere comunque dei mezzi per visualizzare eventuali errori.

+0

Grazie ... ma la mia domanda è su winforms, non asp.net. –

0

Se la "visualizzazione espone i valori come proprietà", ho il sospetto che manchi qualcosa. La distinzione principale tra MVP/MVC e alcuni altri pattern di disaccoppiamento dell'interfaccia utente è che includono un modello, che è destinato a essere il contenitore principale per i dati condivisi dalla vista e dal presentatore o dal controller.

Se si utilizza il modello come contenitore di dati, la responsabilità per la convalida diventa abbastanza chiara. Poiché solo il presentatore (o il controller) effettivamente fa qualcosa oltre a visualizzare i dati, è il responsabile della verifica che i dati siano in uno stato accettabile per l'operazione che sta per eseguire.

L'aggiunta di indicatori visivi di problemi di convalida dei dati a un modulo/finestra di un editor durante la modifica è sicuramente piacevole. Tuttavia, dovrebbe essere considerato più o meno equivalente alla visualizzazione di "eye candy", e dovrebbe essere considerato un add-on per la logica di validazione reale (anche se si basa su metadati o codice condivisi). Il presentatore (o controller) deve rimanere la vera autorità per la validità dei dati e il suo codice di convalida non deve essere ospitato nella vista.

+0

Quindi al presentatore dovrebbe essere consentito l'accesso diretto ai controlli nelle viste ... Stai dicendo che non vuoi un metodo getter/setter nelle viste? Leggi anche il mio aggiornamento alla domanda. –

+0

No, il relatore non dovrebbe avere accesso diretto ai controlli. Le proprietà dei dati (ad es .: il tuo esempio di età) dovrebbero essere sul modello, non sulla vista. Gli errori di parsing degli input (come il tuo esempio in cui un nome è digitato nella casella di testo Age) possono essere difficili da gestire, ma l'approccio di base dovrebbe essere che i dati non analizzabili non dovrebbero mai essere inseriti nel modello. Il meccanismo esatto per affrontare al meglio questo dipenderà dalle tue scelte tecnologiche. Ad esempio, in Window Forms, la scelta giudiziosa di controlli e maschere di input può aiutare a prevenire il problema di analisi. –