Come posso scrivere convalida complessa e logica aziendale che può essere riutilizzata sia nelle modifiche dirette del modello di dati sia nelle modifiche di dialogo in sospeso?

Mi astengo dall'includere la convalida nei miei oggetti del modello di dati. Li rendono POJO molto semplici che non hanno alcuna conoscenza del contenuto dei valori, della logica di business che li guida e dello stato dell'applicazione.

Ho creato classi di verifica separate dal controller e dal modello dati. Questi vengono utilizzati durante l'importazione dei dati e l'interfaccia utente che esegue l'evidenziazione condizionale in base alla validità degli input. Rendo lo sfondo di una tabella di celle rosso chiaro quando i dati in esso contenuti non corrispondono agli input previsti. È semplice avere una serie di classi che sono in grado di verificare input diversi e quindi, in fase di costruzione, associarli con i campi / le celle di input corretti. Sono molto semplici e semplici da usare durante l'importazione dei dati. Intendiamoci, durante l'importazione dei dati, registro solo gli errori nei dati previsti e quindi permetto all'utente di modificare i dati errati. Potrei facilmente aver scelto di rifiutare l'importazione del tutto.

Spero che questo aiuti.

Disegnamo i miei modelli in modo che non si trovino facilmente in uno stato non valido all'inizio. Quindi, quando la mia interfaccia (interfaccia utente o servizio) tenta di inserirla in tale stato, viene generato un errore che posso quindi inviare alla sorgente all'origine del problema.

Il più delle volte questo significa che i miei modelli hanno un metodo chiamato isValid (), che controlla se stesso per cose che non possono essere verificate tramite setter. Questo metodo gestisce anche una logica aziendale più complessa che comprende più del modello.

Validazioni che vengono ripetute in più punti Estraggo le funzioni di utilità xo le classi di convalida, quindi non devo copiare e incollare le convalide. A volte finisco per dover scrivere una convalida del tipo di servizio più complessa, ma è piuttosto raro.

Questo rende i miei modelli abbastanza spessi, tuttavia, so che ovunque io usi quel modello, la convalida è accompagnata da esso. Mantenere la convalida separata, significa dover sempre ricordare di fare la convalida, il che può portare a errori del programmatore. Questo tende anche a rendere più sottile la mia interfaccia (UI, SOAP, JSON ecc.), Poiché si concentra sulla conversione dall'input al modello e risponde alle modifiche del modello, inclusi gli errori di convalida.

Nelle interfacce dell'interfaccia utente, eseguirò alcuni controlli di base su tipi, intervalli e simili, prima di inviare dati al modello che risiede su un server. In alcuni casi, laddove la performance impone, sposterò alcune convalide all'interfaccia utente, ma solo a seconda delle prestazioni.

Questo non significa neanche che i miei modelli siano monolitici. Rompendo le convalide in composizioni separate che chiamo all'interno del mio modello. Significa solo che le convalide stesse sono nascoste all'utente del modello.

Hai un modello di dominio che incapsula la convalida e la logica aziendale, e non è una cosa negativa.

Considera cosa l'architettura "esagonale" implicherebbe per il tuo progetto. In particolare, ti consigliamo di progettare un'interfaccia per il tuo livello di persistenza, consentendo di collegare diversi meccanismi di persistenza come adattatori.

Quando si esegue la business logic per reali, utilizzare l'adattatore del database.

Quando si esegue la logica di business per un'esecuzione fittizia, per verificare le regole di convalida, utilizzare un adattatore fittizio che non riscrive nel database, restituisce un OK se arriva così lontano, oppure elimina alcune eccezioni di convalida se non è così.

Ora il tuo modello di dominio può essere utilizzato in entrambe le situazioni, consentendoti di riutilizzare il codice.