(con digressione sullo Specifications Pattern)

Daniele Armanasco

daniele@armanasco.it

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!

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 considera il contesto – stato coerente nel contesto)

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?

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 …

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

Validazione nell’oggetto di dominio Classico cliente.IsValid()

Validazione di:

Singolo campo (Value validation)

Campi in relazione (Entity Validation)

IDataErrorInfo

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 Specifications Pattern

Ma non serviva per definire query?

Validazione fuori dall’oggetto di d. Esempio con NH Validator

Tratto da: darioquintana.com.ar/blogging/2009/04/02/nhibernate-validator-and-aspnet-mvc/

Validazione di:

Singolo campo (Value validation)

Campi in relazione (Entity Validation)

NH Validator:- non richiede NHibernate (ma vi si trova bene!)- permette di usare attributi o file xml o fluent interface- http://nhforge.org/blogs/nhibernate/archive/2009/05/18/nhibernate-validator-quickstart.aspx

Validazione in più layer E’ necessaria; cerchiamo di riusare le regole!

Esempio: xVal con DataAnnotations (BookingsDemo di Steve Sanderson)

xVal is a validation helper for ASP.NET MVC that lets you use your ownchoice of server-side validation framework (e.g., Microsoft’s DataAnnotations attributes, or Castle Validator, or NHibernateValidation) and dynamically generates client-side validation code fromyour ruleshttp://blog.codeville.net/category/xval/- internazionalizzazione, AJAX

Specifications Pattern Presentato in Domain-Driven Design di Eric Evans

Utile per rispettare il SRP (single responsibilityprinciple)

Rende "stabile“ l'interfaccia di un repository evitando l'aggiunta di un nuovo metodo ogni volta che si necessita di una nuova interrogazione

Non è legato solo alla validazione

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

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

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

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

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

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

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 validatorobject represents a single validation context

"I'm validating this"

http://www.lostechies.com/blogs/jimmy_bogard/archive/2007/10/25/specifications-versus-validators.aspx

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"

Tool di validazione NHibernate Validator

Spring

DataAnnotations

IDataErrorInfo

CSLA Framework

Fluent Validation

EnterpriseLibrary - Validation Application Block (VAB)

xVal

…?

Grazie a tutti! Q & A