Oggi voglio parlare di come sia semplice utilizzare NHibernate come back end per i WCF RIA Services. La maggior parte degli esempi di utilizzo di questa nuova tecnologia mostrano con disarmante semplicità come utilizzare da un client Silverlight un data model creato con EntityFramework o LinqToSql, ma in pochi, tra cui menziono Brad Abrams, hanno dato esempio di come i WCF RIA Services possano essere serviti con la stessa semplicità d’uso, da altri ORM, primo fra tutti, NHibernate. E’ da notare che il caso d’uso “semplice” in cui le classi POCO del domain model sono decorate staticamente, è al di fuori degli scopi di questo articolo ed è già ben documentato da questo post, nella serie di Brad Abrams su SL3 in applicazioni LOB. Qui si vuole che le classi POCO restino tali, senza aggiungere dipendenze per responsabilità che sono di altri strati dell’architettura, e si vuole ottemperare al tanto caro principio “Don’t Repeat Yourself”, evitando di esprimere in più punti le stesse logiche (nel mapping di NHibernate e negli attributi delle classi POCO per i WCF Ria Services)
Cosa c’è già: LinqToEntitiesTypeDescriptor
Dopo questa doverosa premessa passiamo ai fatti, e facciamo un po’ analisi delle logiche che sottintendono alla generazione del DomainContext. Per meglio spiegare tali logiche mi avvarrò di due progetti di esempio, ciascuno dei quali gestisce quattro semplici entità: Order, OrderDetail, Customer e Product, uno mediante EntityFramework e l’altro mediante NHibernate. Farò quindi un po’ di parallelismo tra i due progetti e cercherò di dimostrare come ottenere anche con NHibernate la semplicità di generazione automatica del DomainContext, già ottenibile con EntityFramework
Schema grafico dell’ EDMX di Entity Framework.
Quando si aggiunge un Domain Service a un progetto, Visual studio propone la maschera a seguire, in cui, nel caso il progetto o una referenza del progetto contengono un ObjectContext (o un DataContext di LinqToSql) sarà possibile scegliere quale entity esporre tramite la classe DomainService che si sta creando.
Raccomando di compilare il progetto che contiene l’ObjectContext prima di aggiungere il DomainService o VS non sarà in grado di recuperare le entities. Devo qui fare una precisazione, la maschera di cui sopra offre si la possibilità di scegliere l’ObjectContext/DataContext anche quando esso è contenuto in un altro assembly referenziato dal progetto corrente, ma, in questo caso, l’opzione di generazione delle classi di metadati sarà disabilitata, poiché VS utilizza il sistema delle classi partial per generare tali classi di metadati e se le classi di origine si trovano in un altro assembly il gioco non funziona. Personalmente penso che questa cosa si potesse fare un po’ meglio, soprattutto nell’ottica del wizard che Visual Studio propone, ma poco importa, l’architettura dei WCF RIA Services ci permettono di fare questo ed altro… ;-)
Con le opzioni di cui in finestra, Visual Studio genererà due file, uno per la classe che espone il DomainService (SampleDBService.cs) e uno che contiene una definizione di classe partial per ciascuna classe esposta (SampleDBService.metadata.cs).
Il primo contiene una classe che deriva da LinqToEntitiesDomainService<TContext> al cui interno sono esposti quattro metodi per ciascuna entità esposta, ad esempio per Customer:
public IQueryable<Customers> GetCustomers()
public void InsertCustomers(Customers customers)
public void UpdateCustomers(Customers currentCustomers)
public void DeleteCustomers(Customers customers)
Rappresentanti i 4 metodi CRUD per i quali il wizard di Visual studio ha fatto uso delle naming conventions documentate qui per permettere al DomainService di identificare le funzionalità di ciascun metodo.
Il file SampleDBService.metadata.cs contiene una definizione di classe partial per ciascuna entità esposta, ad esempio per la classe Customer:
[MetadataTypeAttribute(typeof(Customers.CustomersMetadata ))]
public partial class Customers
{ // This class allows you to attach custom attributes to properties
// of the Customers class.
//
// For example, the following marks the Xyz property as a
// required property and specifies the format for valid values:
// [Required]
// [RegularExpression("[A-Z][A-Za-z0-9]*")] // [StringLength(32)]
// public string Xyz { get; set; } internal sealed class CustomersMetadata
{ // Metadata classes are not meant to be instantiated.
private CustomersMetadata()
{ }
public string AddressLine1 { get; set; } public string AddressLine2 { get; set; } public string EMail { get; set; } public string Firstname { get; set; } public int Id { get; set; } public string Lastname { get; set; } public EntityCollection<Orders> Orders { get; set; } public string Phone { get; set; } }
}
In cui è soprattutto da notare l’attributo in testa MetadataTypeAttribute che indica al TypeDescriptor quale classe utilizzare per restituire i Metadati. Il task Msbuild che genera il DomainContext fa uso proprio del TypeDescriptor (invece che direttamente della Reflection) per ottenere tali metadati. Nell’esempio di cui sopra non vi è alcun metadato aggiuntivo, ma la classe rappresenta il punto di ingresso per aggiungerne con semplicità come esemplifica il codice commentato nello snippet sopra.
Tutte le altre informazioni necessarie alla generazione del DomainContext (definito in un file nascosto del progetto Silverlight, SL4_EF_Basic.Web.g.cs) vengono restituiti dalla classe LinqToEntitiesTypeDescriptor che è iniettata nella catena dei descrittori da LinqToEntitiesDomainServiceDescriptionProviderAttribute, a sua volta presente nella classe LinqToEntitiesDomainService<T> da cui SampleDBService deriva.
Qual è dunque il lavoro svolto da LinqToEntitiesTypeDescriptor ? Esso analizza il generico tipo T : ObjectContext della classe cui è applicato e ne inferisce vincoli e relazioni, aggiungendoli dinamicamente all’insieme degli attributi restituiti dal TypeDescriptor. Più in particolare esso aggiunge:
- Key
- ConcurrencyCheck
- StringLength
- RoundTripOriginal
- Required
- TimeStamp
- Editable
- Association
Notare che l’elenco di cui sopra potrebbe non essere completo, non proviene da alcuna fonte ufficiale, bensì è frutto di prove sul campo e dell’insostituibile Reflector.
Preciso che per “Dinamicamente” non intendo “a Runtime” bensì durante la generazione del DomainService da parte del wizard di VS, o durante la generazione del DomainContext da parte del task di MsBuild.
Dopo questo breve lavoro di analisi e un po’ di reverse engineering possiamo elencare che cosa serve per avere con NHibernate la stessa semplicità d’uso dei WCF Ria Services che avremmo con Entity Framework o LinqToSql.
NHibernate TypeDescriptor
Dopo aver capito come le classi di MS restituiscono i metadati, possiamo passare alla definizione di un TypeDescriptor che analizzi una Configuration di NHibernate e restituisca quantomeno gli attributi di cui sopra. Per definire un TypeDescriptor bisogna implementare ICustomTypeDescriptor o derivare dalla classe abstract CustomTypeDescriptor ed eseguire l'override dei metodi appropriati. Ho scelto questo secondo approccio e fatto l’override del costruttore per poter avere riferimento alla Configuration di NHibernate, e del metodo GetProperties () per restituire i PropertyDescriptor contenenti gli attributi appropriati.
public override PropertyDescriptorCollection GetProperties() { if (properties == null )
{ bool hasEntityAttributes = false ;
properties = base .GetProperties();
var list = new List <PropertyDescriptor >();
foreach (PropertyDescriptor descriptor in properties)
{ List <Attribute > attrs = GetEntityMemberAttributes(descriptor).ToList();
if (metaDataAttributes.ContainsKey(descriptor.Name))
attrs.AddRange(metaDataAttributes[descriptor.Name]);
if (attrs.Count() > 0)
{ hasEntityAttributes = true ;
list.Add(new PropertyDescriptorWrapper (descriptor, attrs.ToArray()));
}
else
{ list.Add(descriptor);
}
}
if (hasEntityAttributes)
properties = new PropertyDescriptorCollection (list.ToArray(), true );
}
return properties;
}
Il cuore di tutto è il metodo GetEntityMemberAttributes che dopo aver identificato nel ClassMapping della Configuration di NHibernate, il member descritto dal PropertyDescriptor passato come argomento (la riga di codice a seguire)
member = classMetadata.GetProperty(propertyDescriptor.Name);
esegue una serie di controlli per “mappare” le proprietà di configuration di NHibernate, sugli Attributi necessari ai WCF Ria Services; ad esempio se una proprietà è marcata come “nullable = false”, aggiunge l’attributo “Required” nella table del descrittori.
Le altri classi presenti nel progetto di esempio servono soprattutto a integrare NHibernateTypeDescriptor nella catena: NHibernateMetadataProviderAttribute, che deriva da DomainServiceDescriptionProviderAttribute è l’attributo che è necessario apporre al Domain Service per indicare a .NET il DescriptionProvider da utilizzare, infatti nel metodo CreateProvider (è un override) restituisce un NHibernateTypeDescriptionProvider, che, a sua volta, nel metodo GetTypeDescriptor, istanzia infine il nostro NHibernateTypeDescriptor.
Un punto critico di questo metodo è la determinazione del nome delle associazioni e l’individuazione delle proprietà che rappresentano la chiave di detta associazione.
Uno dei vincoli che i WCF RIA Services impongono è infati la presenza in forma “primitiva” delle chiavi per ciascuna associazione presente. Ad esempio, la classe Order, avendo un associazione con Customer deve avere dei campi che rappresentano la chiave della classe Customer, in questo caso Customer_Id. Dalla configurazione di NHibernate non c’è modo (o meglio non lo conosco) di recuperare tale campo, in quanto lo stesso è esterno alla definizione della foreign key, e l’unico modo che ho trovato è stato quello di ricorrere a delle naming convention, secondo la quale il nome di detti campi deve essere uguale al nome del campo “Classe” + underscore + il nome del campo chiave nella classe destinazione.
Ad esempio Order ha una proprietà Customer, e il campo chiave di Customer si chiama Id, dunque Order deve avere un campo di nome Customer_Id e di tipo uguale al tipo del campo chiave di Customer (int). Se Order avesse un’altra proprietà di tipo Customer, poniamo “BillToCustomer” il nome del campo chiave corrispondente sarebbe stato “BillToCustomer_Id”.
La stessa convenzione è necessaria anche per determinare i campi chiave nel caso di associazioni uno a molti, in cui la chiave è contenuta nella classe destinazione e non nella classe corrente, ad esempio Order ha una ICollection<OrderDetail>, ovviamente i campi di foreign key si trovano nella classe “OrderDetail”, ma occorre una convenzione per utilizzarli. Io ho assunto che i campi chiave necessari si chiamino come il nome della proprietà di relazione (OrderDetails) a cui sottraggo il nome della classe che viene esposta in collection (OrderDetail) reso “plurale” in inglese dall’Inflector (cioè OrderDetails") a cui aggiungo il nome della classe che contiene detta collection (quindi Order"), un underscore e il nome del campo chiave di quest’ultima (cioè il campo chiave di Order, Id). Da quanto affermato ne risulta : Order ha una collection di OrderDetail chiamata OrderDetails, quindi il nome della colonna in OrderDetail che fa da foreign key alla collection deve essere:
OrderDetails - (OrderDetail al plurale) + Order + “_” + Id = Order_Id.
“OrderDetails - (OrderDetail al plurale)” potrebbe sembrare un inutile stravaganza, in quanto in questo caso restituisce una stringa vuota, ma diventa fondamentale nel caso in cui Order abbia due distinte collezioni di OrderDetail; se un ipotetica seconda collection si chiamasse “ShippedOrderDetails” il nome della colonna risultante sarebbe “ShippedOrder_Id”.
Metadata class
Rispetto alla soluzione di MS manca ancora la possibilità di aggiungere degli attributi alle classi POCO senza intaccare le classi stesse, ciò che EntityFramework raggiunge mediante le classi di metadati. Il type descriptor è già predisposto a un’eventualità di questo tipo, infatti nel metodo GetTypeDescriptor di NHibernateTypeDescriptionProvider ricerca all’interno dell’assembly che contiene il DomainService, un tipo con il medesimo nome della classe da descrivere + “_Metadata” , ad esempio per Customer ricerca Customer_Metadata. La classe di metadati fornita viene poi letta da NHibernateTypeDescriptor che aggiunge questi attributi all’insieme.
Conclusioni
A questo punto, per raggiungere un livello di semplicità simile a quello offerto da MS, manca ancora la generazione del DomainService contenente i metodi per il CRUD e la generazione automatica delle classi di metadati. Con un collega abbiamo già realizzato anche questo passaggio, avvalendoci di T4 e del comodissimo T4 Toolbox. Anche in questo caso viene analizzata la configurazione di NHibernate per aggiungere altri attributi, soprattutto di validazione che potrebbero richiedere un messaggio personalizzato. Non dettaglio qui la soluzione, ma se qualcuno è interessato possiamo parlarne e magari si farà un altro post!
Lo scopo di questo post era solo quello di fornire un idea di come decorare in automatico le classi poco di un domain model per nHibernate. Il domain service utilizzato ha solo i metodi “Get” e per di più restituisce una query che non è filtrabile nei confronti della base dati, perdendo di fatto una delle più belle caratteristiche di RIA, ovvero il filtering determinato dal client ma eseguito poi sul server. Grazie a LINQ to NHibernate quest’implementazione è davvero semplice, ma la versione attualmente disponibile come Global Availability ha parecchi limiti, ed è meglio utilizzare quella che verrà poi resa pubblica con NHibernate 3. Magari dettaglierò meglio quest’aspetto, ma… in un altro post! :)
Abbiamo visto una piccola parte dell’eleganza e delle possibilità offerte dai WCF RIA Services, ma non è che la punta dell’iceberg; un WCF RIA Services è a tutti gli effetti un WCF e offre le stesse magnifiche possibilità di personalizzazione del framework WCF. In post successivi conto di affrontare altre tematiche connesse all’utilizzo dei DomainServices, ma…. mi serve qualche spunto! Il blog è ancora neonato e devo fargli un po’ di pubblicità o nessuno ne saprà dell’esistenza e nessuno potrà darmi critiche e consigli su quanto posto!
Dimenticavo! Lo zip con i due progetti di esempio è scaricabile sempre dal mio SkyDrive a questo indirizzo
