Introduzione a .NET RIA Services

Validazione delle entità

Quanto visto fino ad ora può non giustificare l'introduzione di un nuovo framework. Comincia avere senso invece quando è possibile condividere, sfruttando la generazione automatica, anche le logiche di business poste sul server. Si noti infatti che se le logiche lato client si possono implementare anche parzialmente per dare principalmente un responso grafico all'utente, quelle server sono d'obbligo, tenendo soprattutto in considerazione il fatto che un client diverso dalla propria può chiamare DataService.axd e intervenire su entità sulle quali non potrebbe avere accesso.

A tal fine vengono in aiuto dei nuovi attributi di validazione aggiunti con l'assembly System.ComponentModel.DataAnnotations, disponibili sia nel .NET Framework che in Silverlight, che sono:

• RangeAttribute: indica la gamma di valori validi per la proprietà;
• RegularExpressionAttribute: indica una regular expression per effettuare validazioni complesse sul valore;
• RequiredAttribute: indica se la proprietà è obbligatoria;
• StringLengthAttribute: definisce la lunghezza massima di una stringa;
• DataTypeAttribute: definisce la tipologia logica (Email, numero di telefono, password ecc) della proprietà. Questo attributo non effettua un vero controllo sul tipo, ma dà un'informazione su cosa dovrebbe essere;
• CustomValidationAttribute: permette di specificare una classe personalizzata che contiene qualsiasi tipo di logica che si necessiti.

Questi stessi attributi tra le altre cose, sono sfruttati anche dai Dynamic Data Controls introdotti con il Service Pack 1 di ASP.NET 3.5.

Lato server quindi si può procedere con il marcare le proprietà con questi attributi e volendo, marcando anche l'intera classe Message con un CustomValidationAttribute. In alternativa si può marcare la classe Message con l'attributo MetadataType e indicare quale classe, avente i medesimi membri, utilizzare per conoscere gli attributi di validazione. Nell'esempio seguente si sfrutta la parola chiave partial per porre questo attributo sulla classe Message e si difinisce una classe MessageMetadata al solo scopo di rappresentare i metadati di un messaggio:

[MetadataType(typeof(MessageMetadata))] 
public partial class Message 
{ 
    internal class MessageMetadata 
    { 
        [Required(ErrorMessage = "Testo obbligatorio")] 
        public string Text; 
        [Required] 
        [RegularExpression(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$")] 
        public string AuthorEmail; 
    } 
}

Ricompilando l'intera soluzione si ottiene di riflesso la classe Message anche sul client, marcata con gli attributi indicati lato server. Quest'ultimi sono conosciuti e vengono interpretati dai nuovi controlli DataGrid e DataForm e permette quindi di avere in modo automatico un responso visuale qualora l'utente non inserisca il testo o non immetta un'email valida.

L'ulteriore vantaggio è che indipendentemente dai controlli utilizzati per modificare le entità, sia lato client prima di effettuare la Submit, sia lato server non appena giunge la richiesta, si ottiene una validazione di esse, al riparo di qualsiasi possibile errore o possibilità di aggiramento.