1. Validazione degli oggetti di dominio (con digressione sullo SpecificationsPattern) Daniele Armanasco daniele@armanasco.it

2. Modalità di assunzione Discussione nata sulla mailing list del gruppo Mi sono offerto per “prolungare” qui la discussione Ho approfondito alcuni punti per me interessanti, ma: Non sono un esperto, per cui … regolatevi … e intervenite!

3. Poche costanti La validazione (per definizione) non deve modificare lo stato dell'oggetto su cui viene “esercitata” La validazione potrà essere distribuita (IN MODO PERTINENTE!) in diversi layer e applicata più volte La validazione è legata ad un contesto Valido un oggetto prima di persisterlo (classico) Valido un oggetto reidratato da un archivio storico Valido un oggetto prima di passarlo ad un altro sistema (inserisco ordine cliente in AS400) (J. Palermo: The fallacy of the always-valid entity – non considerailcontesto – statocoerentenelcontesto)

4. Tanti fattori variabili Cosa vogliamo dalla validazione? Solo true/false o descrizione errori? Dove validiamo? In quale layer? In quale classe? Nell’oggetto soggetto a validazione o in un’apposita classe? Come validiamo? Come rendiamo leggibili e manutenibili delle regole complesse? Come riutilizziamo le regole senza ridefinirle?

5. Dove validiamo? In quale layer? Nel layer “più basso” in cui la regola ha senso (spesso quindi nel Domain Layer) Rivalidiamo anche in tutti i layer superiori se necessario Esempio: validazione con javascript client-side, validazione server-side nel dominio, validazione nel db Sarebbe bello definire i vincoli una volta sola e farli arrivare agli altri livelli …

6. Dove validiamo? In quale classe? Nell’oggetto di dominio Semplice e facilmente riutilizzabile (se unico contesto!) Fuori dall’oggetto di dominio Non “offusca” l’oggetto di dominio La mia auto non si rabbocca l’olio motore! Evita che l’oggetto di dominio sia accoppiato a molte classi usate solo per la validazione Esempio: per validare lo stato “Delinquent” di una fattura ho bisogno della storia del cliente e delle politiche aziendali

7. Validazione nell’oggetto di dominio Classico cliente.IsValid() Validazione di: Singolo campo (Valuevalidation) Campi in relazione (EntityValidation) IDataErrorInfo

8. Validazione fuori dall’oggetto di d. Evita l’offuscamento della classe di dominio Evita che l’oggetto di dominio abbia accoppiamenti utili solo per la validazione Implementata: Nel classico servizio (ma di dominio!). Che senso ha il Service Layer?! Per mezzo dello SpecificationsPattern Ma non serviva per definire query?

10. permette di usare attributi o file xml o fluent interface

12. SP: Motivazioni – regole complesse Valutare nell’oggetto di dominio: “Offusca” la classe Aumenta l’accoppiamento della classe Regole di valutazione complesse espresse con codice condizionale sono difficili da leggere Nei linguaggi logici questo problema non esiste! I tentativi di implementare le regole logiche con gli oggetti non hanno avuto un gran successo

13. SP: concetti base Prende a prestito il concetto di predicato dei sistemi logici definendo oggetti specializzati (“specification”) Ogni specification: è un piccolo test di verità riceve un oggetto, ne valuta lo stato, torna true/false Si può combinare in AND/OR con altre specification

14. SP: Utilizzi Dobbiamo valutare lo stato di un oggetto in 3 casi: Validazione: verifico se l’oggetto è pronto per … Selezione: seleziono un insieme di oggetti in base allo stato Creazione: definisco le “specifiche” dell’oggetto da creare, non il come

15. SP: Implementazione Il modello concettuale è identico nei 3 casi di utilizzo L’implementazione può differire nei 3 casi Caso tipico: le specification per la validazione filtrano un oggetto in memoria, mentre le specification per la selezione sono implementate in modo da sfruttare le potenzialità dei db relazionali generando codice SQL con clausola WHERE

16. SP: Vantaggi La stessa regola può essere usata per scopi diversi (riuso e uniformità) Ad esempio la specification per creare un oggetto può essere utilizzata per validare l’ouput della factory Le regole possono essere composte come “blocchi logici” Le regole sono leggibili in forma logica

17. SP: Esempio Validazione Nuovo ordine NON valido se: Il cliente è stato bloccato dall’amministrazione Il cliente ha più di 3 ordini insoluti Ordine insoluto = ordine scaduto da 30 gg L’importo dell’ordine supera il limite di credito Il limite di credito è dato da: Se il cliente non ha ordini insoluti  limite di credito concesso al cliente Se il cliente ha ordini insoluti  limite di credito concesso al cliente / 2

18. Specifications versus validators Jimmy Bogard – Validators Matches as many aspects as needed on a single entity Performs negative matching (i.e., returns false if it matches) Executed against a single entity Is intentionally not composable, a single validator object represents a single validation context "I'm validating this" http://www.lostechies.com/blogs/jimmy_bogard/archive/2007/10/25/specifications-versus-validators.aspx

19. Specifications versus validators Jimmy Bogard - Specification Matches a single aspect on a single entity Performs positive matching (i.e., return true if it matches) Executed against a repository or a collection Can be composed into an arbitrarily complex search context, where a multitude of specifications compose one search context "I'm looking for something"

20. Tool di validazione NHibernateValidator Spring DataAnnotations IDataErrorInfo CSLA Framework FluentValidation EnterpriseLibrary - ValidationApplication Block (VAB) xVal …?

21. Grazie a tutti! Q & A