EF v2 Goodness + RIA Services

If you’ve spent any time on the RIA Services forums or attempting to use our LinqToEntitiesDomainService base class yourself, you’ll know that it wasn’t very hard to run into issues :) For example, it was very easy to run into server side issues when processing more complicated graph updates. As I have explained many times in the forums, all of these issues were caused by the fact that EF v1 really didn’t support N-Tier so in our domain layer, we were doing our best to mask that via some non-trivial workarounds. Our team has been in close contact with the EF team over the last year discussing these limitations, and the great news is that in EF v2, they’ve vastly improved the N-Tier support (see the MSDN topic N-Tier Applications With Entity Framework for details) in .NET 4.0. With this new support, we’ve been able to completely overhaul our EF provider. These changes are transparent to you, their main impact being that you should no longer run into any of the previous issues that have plagued the provider. Our breaking changes document describes two changes that were required for us to make these improvements, but I’ll summarize those here:

Only EF models that include FK info are supported – This is the new 4.0 default when creating an EF model, so we’re just lining up our story with that. What this allowed us to do was remove all the dynamic TypeDescriptor stuff we were required to do before to manufacture FK members dynamically from the EF model. This was a bug factory.

Only EF models that embed their mapping info as a resource are supported – This is important for partial trust scenarios where we shouldn’t be attempting to load EF mapping files from disk. Again this is the EF default.

As I mentioned, the changes to our provider were mainly behind the scenes, save for one change to wizard codegen. The Insert method we generate now uses the new ObjectStateManager.ChangeObjectState API:

    1: public void InsertProduct(Product product)
    2: {
    3:     if ((product.EntityState != EntityState.Added))
    4:     {
    5:         if ((product.EntityState != EntityState.Detached))
    6:         {
    7:             this.ObjectContext.ObjectStateManager
    8:                 .ChangeObjectState(product, EntityState.Added);
    9:         }
   10:         else
   11:         {
   12:             this.ObjectContext.AddToProducts(product);
   13:         }
   14:     }
   15: }

In summary, what all this means for me, is a big sigh of relief, since I was the author and maintainer of our EF provider, and had the unfortunate task of answering for all the issues people encountered. It also means I don’t have to spend time in the forums explaining esoteric EF issues and providing workarounds :) What this means for you is a vastly improved EF experience in RIA Services :)

Comments

• Anonymous
  November 29, 2009
  Hi Mathew, I was playing around with WCF RIA and got into a problem with it, maybe you could help me out. I came to the "Only EF models that include FK info are supported" error. however what I did was to create the model first and not generating it from the database, so the foreing keys where out of the model because the designer has no option for them. Is this suppoused to happen by default and the EF foreing keys have to be created by hand or maybe there is a workaround for this? Thanks! Aram

• Anonymous
  November 30, 2009
  The comment has been removed