Friday, November 6, 2009

Shared classes in RIA Services

I have been playing around with RIA .NET Services. It seems like a very powerful and unified way to work with data. I have only skimmed the surface of it's capabilities, but I found a few curious things I want to see if others are experiencing too.

A very cool feature of RIA Service is the concept of shared classes. Imagine you want to create a derived property on a data class (in my case, FullName = FirstName + " " LastName). You write that as a partial class, in a file named *.shared.cs (or *.shared.vb if you are using VB). I like how they have used convention over config for a lot of this in RIA Services. My code looked like


   1:      public partial class Employee
   2:      {
   3:          public string FullName
   4:          {
   5:              get{return FirstName + " " + LastName};
   6:          }
   7:      }
This worked fine, and my client displayed FullName without any problem. But, I couldn't edit the data anymore. Once I added a setter to the property, everything was good again.


   1:      public partial class Employee
   2:      {
   3:          public string FullName
   4:          {
   5:              get { return FirstName + " " + LastName };
   6:              set { }
   7:          }
   8:      }
I guess this is because of how the code is generated on the client side, but haven't stepped through to see why exactly this is happening.

Another thing I have found is that, when Visual Studio generates the proxy/shared code on the client side, the folder and the files are not automatically included in the project. You have to include the Generated_Code folder and it's files manually.

Overall, I find the metadata-based validation and edit/batch edit/offline capabilities of RIA .NET services very exciting. Now, in the next version, if it starts generating validation metadata from constraints in the database, that will be uber-cool.