Modelli per il mantenimento dello stato del modello in tempo reale

Questo è un problema comune nella convalida dei dati; Quando si inseriscono nuovi dati nel sistema, prima che qualsiasi informazione venga inserita dall'utente, lo stato di lavoro predefinito dell'oggetto (principalmente null) è uno stato non valido per praticamente tutti gli altri processi del proprio sistema.

La convalida è sempre dipendente dal contesto. Se, per esempio, hai un requisito aziendale che tutti i record "persone" inseriti devono avere almeno un nome e un cognome, allora nessuna convalida a livello di campo (che verrebbe eseguita solo quando si imposta un campo, e quindi non prenderebbe un errore nell'impostazione dell'altro campo), né convalida a livello di modello (che, se invocato in tempo reale, restituirebbe un errore di convalida per questa regola quando si immette il nome perché il cognome non è valido) funzionerebbe sempre quando implementato in modo ingenuo .

Invece, il tuo modello di dominio deve essere reso abbastanza intelligente da sapere quando è ok essere in uno stato incoerente, e quando non lo è. Di solito, ciò si ottiene fornendo una specie di scope o identificatore di contesto nelle routine di validazione:

• Quando si immette un singolo campo, è possibile e dovrebbe solo convalidare le regole che definiscono il comportamento di quel singolo campo. Semplicemente non puoi richiedere all'utente di inserire un cognome quando sta tentando di specificare un nome in un nuovo record, e viceversa.

• In alcuni punti, potresti sapere che un sottoinsieme dell'oggetto dovrebbe ora essere in uno stato coerente. Questo può accadere quando si compila un modulo di più pagine e si tenta di continuare alla pagina successiva; a quel punto, è possibile convalidare regole che coinvolgono uno o più campi nella pagina corrente. Ciò include tutte le convalide a livello di campo, ma anche ulteriori convalide multi-campo, come assicurarsi che gli intervalli di date composti da una data di inizio e di fine siano validi (data di fine dopo la data di inizio, per esempio) e che una persona abbia sia una prima sia una cognome.

  A volte, se i dati di una pagina dipendono da dati in una pagina precedente, potresti essere in grado di fare anche queste convalide, ma in quel caso quelle convalide non dovrebbero impedire a una persona di tornare indietro per correggere un errore; dovrebbe solo impedire all'utente di continuare ora che c'è un'ovvia incoerenza. Comprendere che consentire la validazione dei valori in tempo reale all'interno di una pagina o su più pagine può introdurre un accoppiamento indesiderato; le regole di validazione devono incorporare una logica che dipende dalla struttura del livello View.

• Infine, quando si mantiene un oggetto (o lo si recupera dalla persistenza per utilizzarlo dietro le quinte), deve essere del tutto coerente. Ciò include tutte le convalide dei campi, tutte le convalide a livello di pagina e inoltre tutte le regole che riguardano la diffusione dei dati su più pagine.

Le regole che il modello deve soddisfare a uno di questi livelli possono impedire l'esecuzione corretta del programma quando eseguito a un livello inferiore. È spesso possibile includere l'ambito o il livello di convalida in una serie di regole che possono essere eseguite con una chiamata al metodo, consentendo quindi il passaggio della regola se i dati sono "abbastanza coerenti" per un particolare livello di convalida. Tuttavia, farlo spesso accoppia il dominio (o il controller) a una vista molto specifica, rendendo fragile il design; se si desidera spostare un campo in una pagina diversa della vista, è possibile che le routine di convalida nel controller o nel modello di dati vengano modificate per riflettere ciò. Potrebbe non esserci un buon metodo se vuoi convalidare ogni regola il prima possibile.

Ti suggerisco di abbandonare la convalida a livello di campo e, in effetti, di allontanarti il più possibile dalla struttura dei campi.

Invece, concentrati sul modello di progettazione OO di "l'istanza possiede dati e modella tutti i comportamenti" - ha un metodo "cambia nome" che prende gli input appropriati ed esegue la mutazione interna, nascondendo i dettagli dell'implementazione dal dei consumatori.

In generale, suggerisco, preferisco i metodi che sono atomici e quell'intenzione di cattura: SetName, piuttosto che SetFirstName. In questo modo l'elaborazione dell'azione è completa e il tuo oggetto è valido prima e dopo la chiamata al metodo.

Questi metodi di oggetti del modello si associano in modo abbastanza naturale all'API che finirai per rivelare all'utente: vogliono cambiare il nome, quindi modellarlo come una singola chiamata dall'interfaccia utente al modello e viceversa.

Ciò aiuta ad isolare le parti del sistema l'una dall'altra ed evita di accoppiare accidentalmente parti del software insieme esponendo dati interni come "come conservo il nome" ai consumatori dell'oggetto.

Realizzerei convalida sia a livello di campo che a livello di modello. Sul lato dell'interfaccia utente, controlla che i campi richiesti siano compilati e visualizzi un errore in caso contrario. Semplicistico - e intenzionalmente.

Quindi, all'interno del modello, crea una funzione #validate. Controlla lo stato dell'oggetto e restituisce true se il modello è valido, false in caso contrario. Il tuo schema di base è quello di convalidare prima, e in caso di successo, applicare le modifiche. Se la convalida fallisce, elimina le modifiche. Può anche essere utile se la convalida restituisce un messaggio di errore che indica perché la convalida non è riuscita.

Se il tuo modello è composto da molti oggetti diversi. ognuno riceve la propria chiamata valida e la parte superiore dell'albero raccoglie solo i risultati di ciascuna sottocategoria.