Entity Framework 5 Code First and WCF Ria Services

Starting from a question on stackoverflow site, I thought it could be useful to publish a working sample of Entity Framework 5 and WCF ria Services tight together.
Everything it’s pretty simple but there are some not obvious pitfalls that can lead to tedious waste of time.
First thing to do, create a new Silverlight Application and don’t forget to put a mark on “Enable WCF RIA Services” as in the image below

then, server side, on the project that will host our silverlight application (here named EFCodeFirst _WCFRiaDemo.Web) right click the project, then select “Manage Nuget Packages”; look for entity framework then click on install as in the image below

In my demo I’ll use the domain model classes from another assembly, as an usual path with POCO domain model, so let’s reference in the EFCodeFirst _WCFRiaDemo.Web project the assembly that contains our classes.
I’ll use a very basic one

Please note the BlogId field in the Post class. It really looks like the db that is leaking into the model, and indeed it is, but… that’s the way WCF Ria Services work with relations. Just pretend not to see this field
Then create the DbContext including the related mapping, as in the snip below

public class BlogContext : DbContext
    {
        public BlogContext() : 
            base("BlogContext")
        {

        }
        public DbSet<Blog> Blogs { get; protected set; }

        public DbSet<Post> Posts { get; protected set; }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            //Here goes our custom mapping
            //we can comment out the row below and completely customize the entities mapping
            //base.OnModelCreating(modelBuilder);

            modelBuilder.Entity<Post>()
                .HasRequired(x => x.Blog)
                .WithMany(x => x.Posts)
                .HasForeignKey(x => x.BlogId);


        }
    }

and in the web.config add the connection strings section and relevant info

<connectionStrings>
    <add name="BlogContext" connectionString="Data Source=.\SQLEXPRESS; AttachDBFilename=|DataDirectory|\WcfRiaDemo.mdf;Integrated Security=SSPI; MultipleActiveResultSets=True;User Instance=true" providerName="System.Data.SqlClient" />
</connectionStrings>

I’ve leveraged Package Manager Console to create my database running in it Enable-Migrations –EnableAutomaticMigrations

Now, our DbContext should be up and running, let’s add out DomainService class. I’m not a fan of shining wizard, so I’ll not leverage automatic DomainServices creation, taking into account that it needs some tricks in order to work with EF Code First. I’ll rather add a DbDomainService manually. Consider also, that this is the way you’ll normally deal with when adding classes and methods to your model.

In order to work with EntityFramework and take advantages of mapping info defined into the DbContext, we need to derive our DomainContext from the DbDomainService class. This is a class defined in the WCF Ria Services tookit, available here.

Then, “expose” our classes to the client, adding methods these

    [EnableClientAccess()]
    public class WCFRiaDemoDomainService : DbDomainService<BlogContext>
    {
        [Query]
        public IQueryable<Blog> GetBlogs()
        {
            return this.DbContext.Blogs;
        }

        [Query]
        public IQueryable<Post> GetPosts()
        {
            return this.DbContext.Posts;
        }
    }

The QueryAttribute  it’s not strictly needed as it will be picked from convention (the method returns an IQueryable<T>) however, I like to mark those methods.

Please note that I’m not exposing the related Insert/Delete/Update methods, so my entity will be generated as read-only.


Now come the tricky part: if we try to build the client it will NOT generate our DomainContext, but rather just the WebContext and no Classes.

This come from a version compatibility issue between the code generator and entitiy framework. The Code generator will look for EntityFramework v4.2, will of course not found it, and will not generate our classes and unfortunately will not notify us of such problem.

The solution I usually use rely on, is assembly binding redirect. Putting the lines below into our web.config will trick the code generator that finally will generate our proxy

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

A final note: Consider that the proxy generator come in two flavours: the CodeDom generator (the one that we are using here) and the T4 based code generator. You can learn how to use and leverage it from the (no long updated) blog of varun puranik

That’s it for now. I’ve attached the solution for everyone to download and take a look.

WCF Ria Services overcoming limitations on "Return Types”

I’m a fan of WCF Ria Services,  however it sometimes have strange limitations whose motivations doens’t appears obvious. One of them I believe it’s the limitation on types that a DomainServices can returns.
If you try to return for example a IEnumerable<IList<string>> you’ll get a message like that

Operation named 'MyOperation' does not conform to the required signature. Return types must be an entity or complex type, a collection of entities or complex types, or one of the predefined serializable types.

A simple way to overcome this limitation is to “pre-serialize” your object. I use a couple of methods to serialize/deserialize both client and server side

public static class Serialization
    {
        public static string Serialize<T>(T obj)
        {
            var ms = new MemoryStream();
            var ser = new DataContractSerializer(typeof (T));
            ser.WriteObject(ms, obj);
            byte[] array = ms.ToArray();
            ms.Close();
            return Encoding.UTF8.GetString(array, 0, array.Length);
        }

        public static T Deserialize<T>(string obj) where T : class
        {
            if (obj == null)
                return null;
            var serializer = new DataContractSerializer(typeof (T));
            var stream = new MemoryStream(Encoding.UTF8.GetBytes(obj));
            var result = serializer.ReadObject(stream) as T;
            return result;
        }
    }

So, Server side I use something like

[Invoke]
public IEnumerable<string> MyOperation()
{
    List<string> list1 = new List<string>(){"ciao", "a" , "tutti"};
    List<string> list2 = new List<string>(){"hello", "world"};
    List<string> listOfSerializedList = new List<string>();
    listOfSerializedList.Add(Serialize(list1));
    listOfSerializedList.Add(Serialize(list2));
    return listOfSerializedList;
}

while client side

var myOperationResult = myDomainContext.MyOperation();
List<List<string>> myRealResult = new List<List<string>> ();
foreach (var myList in myOperationResult )
{
    myRealResult.Add(Deserialize<List<string>>(myList));
}

Of  course the code is just a proof of concept, and it’s better to package it in more “productive” methods but it should get the idea behind it.
Hope this helps

WCF RIA Services e NHibernate, un passo avanti: NHibernate TypeDescriptor

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