(I’m including Part 1 in the title because there’s a possibility I’ll be adding to this topic.)
If you look for information about using Plain Old CLR Objects with RIA services (or using RIA services without Linq to Entities) you’ll see a few articles telling you how easy it is to use your own business objects from a DomainService - If you simply stick the [Key] attribute above a property that uniquely identifies your object, all will be well.
Except it’s not necessarily true. It all depends on how ‘smart’ your objects are, and how you expect it to work. If you have the (accurate) mental model of the objects being serialized and deserialized between client and server then you’re probably going to be OK.
On the other hand, if you’re working with less dumb objects that do more than just hold database fields, and you think of the RIA services as more like remoting then, like me, you’re going to be disappointed.
To be honest, my first clue should have been that everything has to be get/set and the classes need parameterless constructors. My ‘business objects’ had some internal state that they used to map themselves back to the database, so I marked that with [Exclude] attributes.
I tried sending these objects to the client via a query method, and then accepting them back to the server as parameters on an [Invoke] method. All the internal state had gone. But that was because they weren’t the same objects I returned from the query, they were newly constructed objects with the same values in their public properties.
The lesson was that there’s no reference tracking going on between client and server. If you send the client an object, it will be cloned on the client side. If that object is modified and passed back, the server gets a new object with all the values – not the original object with new values applied.
This probably seems obvious to many people, particularly those who have used similar frameworks (like the view model stuff in ASP.NET MVC) but it’s not something I saw explicitly called out in any of the explanations of using Silverlight RIA services with POCO.