Come considerare concettualmente e implementare le regole dell'interfaccia utente per numerosi controlli e input di dati?

Naviga le tue risposte
2

Ho un'interfaccia utente con numerosi controlli e input di dati. Pulsanti, campi di testo e caselle di controllo, ecc. Immagina che esistano le seguenti "regole" per un'interfaccia utente di esempio con 2 di questi controlli:

  • B2 non può essere utilizzato fino a quando TF1 e TF2 hanno entrambi valori
  • TF2 non può essere inserito fino a quando TF1 non ha un valore
  • CB2 non può essere controllato a meno che TF1 abbia un valore
  • CB2 non può essere controllato a meno che CB1 sia selezionato

Queste regole sono arbitrarie qui, ma ho una varietà di regole aziendali che alla fine regoleranno la funzionalità dell'interfaccia utente.

Vorrei implementare la logica per questo nel mio codice dell'interfaccia utente per far rispettare queste regole. Tuttavia, sto avendo difficoltà a determinare un buon modo per farlo. Posso pensare a due modi principali ma non sono nemmeno un fan di entrambi.

Metodo 1: aggiunta della logica a ciascun callback del controllo

Un modo per farlo sarebbe quello di aggiungere i controlli logici al callback di ciascun metodo. Quindi, per la prima regola, nel codice associato a B2, includere controlli codificati come if TF1 == "" e if TF2 == "" . Non sono un fan di questa idea, perché ho intenzione di disperdere ogni sequenza / logica in ogni parte della mia interfaccia utente e sembra inevitabile che a volte questo processo risulti oscuro e impossibile da rintracciare i bug. Sembra anche che la manutenzione sia incredibilmente complessa.

Metodo 2: crea raccolta di tutte le regole

Il modo in cui mi sto proponendo è la costruzione di una serie di regole. Il primo passo sarebbe definire un insieme di regole per "passare" per ogni tipo di controllo e le sue ricerche associate, come ad esempio:

  • Per le caselle di controllo, "passa" seleziona "vero", "non riesce" se falso
  • Per le caselle di testo, "passa" se non è vuoto, "non riesce" if=""

Posso quindi creare una raccolta di tutti i prerequisiti di verifica pass / fail per ciascun componente dell'interfaccia utente e dei componenti associati. Questo può essere astratto in un singolo metodo di controllo chiamato in ogni azione dell'interfaccia utente come:

  • myChecker (mControlName)

dove myChecker è un metodo che scorre l'elenco di tutte le regole di corrispondenza, le controlla e restituisce vero / falso in base al passaggio delle regole. Questo metodo può essere chiamato da ciascun controllo dell'interfaccia utente prima che avvenga qualsiasi logica specifica del controllo.

Questo è bello, ma sembra creare le regole e non dimenticare che alcune potrebbero essere anche più complesse del primo metodo. Inoltre, tutti i tipi di controllo devono avere un criterio "pass / fail" o il metodo myChecker potrebbe diventare ridicolmente complesso con molte dichiarazioni difficili da leggere se.

Mi manca qualcosa? Ci deve essere un modello più chiaramente definito o una strategia migliore per incorporare questi tipi di validazione / regole in un'interfaccia utente.

    
posta enderland 13.01.2014 - 22:12
fonte

3 risposte

4

Penso che tu sia sulla strada giusta con il metodo 2 (anche se in alcuni casi potrebbe essere eccessivo, non penso che sia nemmeno troppo vicino al tuo caso).

Ci sono alcuni pattern almeno in qualche modo rilevanti: MVC, MVVM, MVP ti aiuteranno a spostare la logica per "passare" dai controlli dell'interfaccia utente. Al posto della logica aziendale che si verifica nel controllo, un altro codice potrebbe eseguire la logica aziendale, aggiornare un modello, quindi legare i dati dal modello ai controlli.

Puoi eseguire un bind di dati più manuale se stai utilizzando un framework vecchio come VB6 o, dio non voglia, Microsoft Access .

Questo può sembrare un lavoro extra per fare la stessa cosa, ma ti permette di scrivere test unitari della logica aziendale. Può essere utile per alcuni problemi di concorrenza, poiché l'aggiornamento del modello non avvia immediatamente l'attivazione degli eventi dell'interfaccia utente.

Esistono anche modi per rendere più gestibile la logica di business rispetto a una foresta di istruzioni if. Di solito a quel punto si cambiano le regole che governano le istruzioni if / then in qualsiasi struttura dati in grado di catturarle. Quindi esegui la struttura dei dati e applica le regole. Spesso questo è più facile da seguire rispetto al codice, ma dal momento che le regole aziendali potrebbero potenzialmente essere qualsiasi cosa non c'è un vero caso generale da seguire.

    
risposta data 13.01.2014 - 23:30
fonte
2

Metodo 3: aggiunta della logica personalizzata a ciascun callback di controllo e una raccolta di regole (condivise) :

Cercare di creare un metodo di controllo unico che funzioni per tutti i controlli dell'interfaccia utente potrebbe rivelarsi molto difficile. ... e peggio, potrebbe dover contenere così tante opzioni ed eccezioni che sarà troppo difficile da gestire e difficile da gestire. In genere è una cattiva idea creare un metodo kitchen sink .

L'aggiunta di logica a ciascuna callback di controllo non è poi così male. Se ci sono molti controlli con la stessa / logica simile, si dovrebbe considerare tale parte, e tutti possono chiamare lo stesso controllo di validazione. In realtà, i bug dovrebbero essere più facili da rintracciare, poiché non esiste un metodo mostruoso che gestisca ogni cosa a cui guardare ogni volta. I bug saranno più locali per ogni controllo.

    
risposta data 13.01.2014 - 23:14
fonte
1

Se ci sono solo poche regole, sono solo su uno schermo e non cambiano molto, quindi andrei con il primo metodo.

Se ci sono molte regole, su molti schermi e possono cambiare nel tempo, la complessità aggiunta del secondo metodo tornerà a una migliore manutenzione e quindi a uno sviluppo più rapido.

    
risposta data 13.01.2014 - 22:15
fonte

Leggi altre domande sui tag

Come fa un motore di scacchi a decidere quale mossa fare? Dove posizionare le fonti dei file di configurazione