RIA, a picky mistress

I mentioned quite awhile ago that I was interested in the upcoming (now more or less here) flow-down business objects aka WCF RIA Services. The idea behind the technology is that you can create the business objects on the server and use them from the client in a more streamlined way than was possible before. I started my Silverlight LOB application during the Silverlight 2 beta, and as such found some situations where I had to create analogous classes in the Silverlight code base and on the server as a .NET class, then use a conversion routine to convert the server version to the Silverlight version in order to perform any client-side logic, support a ViewModel etc.

During a recent code freeze I finally had the opportunity to investigate the now-in-beta RIA services to see whether they will work for us. Here's what I discovered: they are VERY VERY VERY tightly bound to the ADO.NET Data Services Entity Framework. As in you have to use it. By default, the Entity Framework requires you tightly bind to a specific database. That's not possible for us because each customer project has its own case and schema. We could try to work with a custom entity framework without such bindings but I am not yet convinced that that isn't even more work for less benefit. We still couldn't use the DomainService class with anything that involved dynamic schema, which is a not-insignificant portion of the application. Given that we really only have one area where we have significant redundancy between the Silverlight and server-side object logic, I am not seeing a benefit to changing how this particular system works.

As I reminded one of my devs when he was researching the technology on his own, just because we COULD generate a custom and dynamic entity model, doesn't mean we SHOULD. There needs to be a compelling reason to do it, which as of yet I haven't found. I think the main place where I would see utility in this technology at the office is in the authentication service, since that would interface with a "master" database instead of project specific ones, and I may decide to go this route.

Now, for some of my personal projects that do have a single database this is a super neat and easy alternative to an "old school" Silverlight WCF service. Given what a pain it is to deploy a WCF application to service providers as I mentioned in my previous post, I am hoping this will be more a more straight forward deployment scenario.

If any of you have worked with custom entity frameworks where you were not tightly bound to an individual instance or schema and have thoughts on how it worked for you and whether it was worth it, I'd love to hear them.