alla fine ci sono riuscito...ecco la jankyValidation...
un tool che può aiutare nella definizione delle regole di validazione per i nostri business object, ma anche per le nostre form...
mi farebbe piacere ricevere feedback da chiunque, il codice lo rendo disponibile a tutti, per adesso tramite download, poi magari se la cosa piace, facciamo un progetto su sourceforge e se qualcuno vuole collaborare alle estensioni sarà il benvenuto.
Devo ringraziare
Igor con cui ho avuto modo di (chat)chiacchierare sull'utilizzo del tool, mi ha fatto da beta tester offrendomi ricchi spunti di miglioramento, e anche
Marco con cui ho avuto qualche scambio di idee sul modo di vedere la validazione. Dovevamo avere uno scambio di idee anche con
Andrea davanti ad una birra ma purtroppo non ci parliamo più da quando è successo il
fattaccio...gh...gh...gh...!
cominciamo con ordine...
Validazione, scuole di pensieroPartiamo da un po di teoria sulla validazione: le varie scuole di pensiero vedono la situazione in due modi diversi:
Context Free Validation (
qualcuno che la pensa così)
Ogni oggetto di business ha una sola validazione ammissibile. L'oggetto o è valido o non lo è, rispetto ad set di regole che agiscono sulle sue proprietà.
Contextual Validation (e qualcun altro che la pensa così:
Fowler e
M.rkino)
Un oggetto di business può essere sottoposto a più operazioni. Per ogni operazione applicabile, (o per meglio dire, nel "contesto" di quella operazione) l'oggetto deve soddisfare un determinato set di regole. A seconda dell'operazione da svolgere il set di regole può cambiare, sia nei parametri, sia nelle definizioni di nuove regole.
Per esperienza personale mi sono sempre trovato di fronte a casi del secondo tipo, vabbè...dipende anche fortemente come viene strutturato il proprio domain model, ma in certi casi non si scappa. Nel caso in cui l'operazione ammissibile per un oggetto è unica i due modelli coincidono (A ME MAI!).
Nel primo caso si sono sviluppati molti tool (tipo
questo del nostro
mitico ill.mo pres.) che agiscono in modo dichiarativo, con attributi per decorare le proprietà del proprio object model.
Il tool che invece vi volevo sottoporre è radicalmente diverso come concezione, e più che dichiarativo è classicamente programmatico (niente attributi) e basato sul concetto di contesto di validazione inerente ad una specifica operazione.
PS: visto che sto per "criticare" anche la soluzione del
pres, e lui sicuramente mi farà del male fisico a colpi architetturali uccidendomi o devastandomi, vi volevo
dire
che...
è stato bello conoscervi e partecipare a questa community :-(Validazione per Attributi, Controindicazioni
Gli attributi sono una buona soluzione nella validazione context free?
Si possono usare attributi anche nelle validazioni contestuali?Queste sono le controindicazioni che ho incontrato nei framework di validazione basati su attributi che ho visto, e che qui riassumo:
1. Regole di Validazione legate a più property dell'oggetto di business
Possono esistere regole di validazione che riguardino più proprietà contermporaneamente.
Esempio: Un oggetto di business possiede due liste di fornitori. Per essere valido, ogni lista non deve contenere elementi dell'altra.
Su quale property mettiamo l'attributo?
2. Il CLR non garantisce l'ordine in cui gli attributi vengono ordinati.
Se ho la necessità di specificare un ordine in cui le regole devono essere eseguite, l'ordine degli attributi mi mette in seria difficolta, o quanto meno devo pensare a qualcosa di specifico. Ne ha data dimostrazione il nostro buon Adrian, io già conoscevo questa piccola mancanza, poichè il mapping delle property di NHibernate soffre dello stesso problema (per quelli che usano le annotation, io no!) e che viene risolto con l'inserimento di un ordinale...mamma mia che brutto!
3. Non è possibile specificare un OR
L'oggetto è valido se "tutte" le regole definite da attributi sono valide. Tutte le regole vengono quindi validante in AND logico. Nell'esempio che introdurrò vi proporrò un problema di business dove alcune regole devono essere validate in OR (cosa piuttosto comune)
...e questo solo nel caso in cui si faccia validazione context free, se poi invece si pretende di fare contextual validation si incappa anche in:
4. I set di regole in contesti di operazioni diverse possono cambiare radicalmente
Ogni contesto può definire set di regole totalmente diverse rispetto ad un altro contesto di validazione.
5. Una stessa regola (anche insistendo su una specifica property), può avere parametri diversi a seconda del contesto di validazione.
...inoltre, a prescindere dal tipo di validazione, non dovremmo pensare anche a quei poveretti che sviluppano l'interfaccia, che sono pieni di errorProvider (winform) o label/validator (web) accanto ai controlli e che dai tool esistenti invece ottengono una stringa cumulativa degli errori avvenuti?
Perchè perdere l'ottimo modo di visualizzazione tramite errorProvider? pensiamo anche a loro! :-)
Da queste premesse quasi 4 mesi fa completai una libreria per evitare il lavoro ripetitivo.
Recentemente ci è voluta una lustratina a colpi di refactoring e un aggiornamento al fwk 2.0, per renderla presentabile...
(a seguire la seconda parte)