My first thoughts on WCF RIA Services

While working on my demo code for my full-day talk on Software Development Practices in Practice I was a bit ambitious and introduced both Silverlight 4 and WCF RIA Services. Apart from the fact that the preparation caused a bit too much of my social live, I ran in some things I don’t really like and hopefully will be improved in next versions of the WCF RIA Services. If not, I’ll have to remove it from my reference architecture.

• The generated domain context class does not include an interface. If you want to TDD your view model classes, you have no choice then to introduce a thin adapter. Moreover, classes like EntityQuery and LoadOperation require all kinds of constructor arguments, so you cannot easily use a mocking framework.
  
• I use a domain model to hide all the database details from my object-oriented design, so I surely do not want to see any foreign key fields in my service layer. The composition functionality in RIA requires the use of the [Association] attribute to specify how my childs are related to my parent and that involves referring to the identifying properties that relate the two together. In fact, you have to use literal text for that, so be careful if you rename your properties.
  
• There is no built-in support for reloading the client data after submitting the changes to the server. And even if you explicitly chain a reload after your call to SubmitChanges, you have to be aware that it will not remove anything that was deleted by somebody else. In fact, if your entities have a server-generated identifier, you may end up with duplicates (one with and one without identifier). See this post for a workaround.