Mi domando quale sia il modo migliore e corretto di gestire le proprietà di una entità. Voglio dire, dovendo fare operazioni all'interno di metodi della proprietà, è corretto usare il campo relativo alla proprietà oppure è buona regola usare sempre la proprietà passando per il setter e il getter?
In aggiunta, se ho una proprietà di tipo string che voglio che contenga max 30 caratteri maiuscoli, è corretto fare queste conversioni all'interno del setter oppure fa parte della validazione, quindi in un metodo Validate della entità controllo le proprietà e faccio le dovute correzioni?
Per quanto riguarda invece la validazione, è corretto dire che una entità che contiene una lista di entità (es. fattura, posizioni fattura) è in uno stato non valido anche se tutte le proprietà sono valide ma ci sono entità della lista (posizioni fattura) non valide?
A quest'ultima domanda il mio pesiero è che la fattura non è valida se ci sono posizioni non valide, in quanto considero l'oggetto fattura nel suo insieme.
Antonio Budano
Wow quante domande in un singolo post :D scherzo. Allora per le proprietà il problema non si pone, il field è solitamente privato per cui sei obbligato a passare dal setter e getter, è la base dell'incapsulamento.
Per la lunghezza dei caratteri, direi che il setter di una proprietà non deve fare nulla assolutamente, ma è compito della validazione. SE segui i principi di Nilson ci sono due validazioni, una è quella di business, (Es. non puoi avere ordini di totale maggiore di 300€ non validati da un manager), mentre esiste una validazione a livello di salvataggio che dice se l'entità (che è valida dal punto di vista del business) può comuhnque essere salvata nel data store. A questo punto non è giusto fare correzioni (tipo troncamenti) ma deve esser notificato all'utente che l'oggetto nn è valido.
Per la validazione di entità composte sono daccordo con te, se segui il principio di segregazione in Aggregati, la validazione è sempre fatta dalla root. Ovvero se un ordine ha al suo interno una linea d'ordine o un "buonoSconto" che non passano la validazinoe, l'ordine intero non può essere validato. Ma questo discende dal fatto che tu consideri sempre l'insieme degli oggetti e mai la singola linea d'ordine o il buono sconto da solo.
Alk.
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
Bene, concordo che il setter non debba fare assolutamente nulla e che il controllo sulla lunghezza/case debba essere fatto in fase di validazione.
Per gestire il numero massimo di caratteri ammessi/case, conviene impostare questi valori nella UI ad esempio impostando MaxLenght CharacterCasing di una TextBox oppure è meglio non vincolare la UI a regole che potrebbero cambiare in futuro?
Dipende anche dalla libreria di validazione, io direi che vanno in entrambi, ovvero la maxlenght nella UI evita all'utente di fare errori, è un aiuto utile, però poi devi rivalidare prima di salvare/modificare, perché le vaidazione della ui non sono da prendere come "Sicure".
alk.
Cosa usi di solito per fare le validazioni?
Per un progetto ho usato la validation application block di entlib, altrimenti avevo fatto tempo fa una mia semplicissima libreria che funzionava tramite attributi/configurazione, nulla di complicato.
Solitamente infatti si usano validatori lato UI, poi chiaramente si ripassa per uno strato di validazione business che principalmente però mi valida lunghezza campi, range di validità etc. Per regole molto più custom e relative ad uno specifico business spesso faccio funzioni ad hoc nei servizi. Ex. se ho un servizio per gli ordini che ha una funzione ConfirmOrder, li dentro magari si inserisce della logica di validazione custom per capire se l'ordine è valido.