RIA Services - v1 Shipped!

@Rick Arthur
Did you check out the Book Club sample I have used in conferences and in couple of recent blog posts, incl. the pointer to it in this blog post? It has those insert/delete. I'd recommend checking it out.

True deletes, as in deleting data from a database is rare in real apps. Typically data is tombstoned rather than getting rid of it completely. That said the beauty is from the client's perspective the operation might be a delete, and ria services allows you to implement back-end logic to either truly delete, or simply tombstone. Doesn't matter... that is an implementation detail of the server/business logic.

@John Kears
You've identified what might have been the most controversial change in behavior. The fact is the change was motivated when we thought through the OData scenario, but it applies beyond that.

In OData, ETags (the portion of the entity used to determine concurrency checks, and the bit that can be used to reconstitute original values) is computed when entities are queried and sent from the server to the client. It would be incorrect to bloat the ETag with a copy of the entire entity, i.e. all members. Only specific fields used for concurrency check by the DAL, or specific fields used by the business logic in the DomainService should be sent back. This requires the developer to step in by placing [Roundtrip] on members that need to be sent back... note we do infer what needs to be round-tripped by mapping DAL-specific concurrency metadata into [Roundtrip] automatically.

Some other scenarios where this matters:
- In ASP.NET DomainDataSource, fields need to be roundtripped via view state. We wouldn't want view state to be bloated.
- In the mainline Silverlight scenario, sometimes entities contain large blob/text fields that might not need roundtripping.
- Also in the mainline scenario, sometimes having the full original entity around might tempt the developer to base security-like checks by comparing against the original, when instead those checks should be performed by retrieving values from the db.

So bottomline, it overall seemed appropriate to change the behavior. In the end I think it is the right default, as one can always opt-in into more, and if the model instead was to opt-out, most developers wouldn't even realize they could/should. I think the biggest pain really was the change in behavior, as opposed to the new behavior itself, as the change either caused some breakages, or leaves some people perplexed. If we had an opt-in model from the get-go, I think it would be lessened the pain to some degree.

For your audit scenario, I agree you want the original values. Depending on your app you might need to audit specific members, and would need to add [Roundtrip] to just those members.

Hope that helps!

@Osku
I'd suggest checking out my BookClub app - it isn't the exact same master/detail scenario, but it does show editing/inserting using a view model pattern instead, that I think is better than using collection views.

Essentially, you have a form, with ok/cancel buttons that invoke methods on the view model and that view model can then turn around and work against Entities, EntitySets, EntityCollections etc. all without using any collection views.

Hope that helps...

@Pat
Your best bet is to define Foo with the fixed set of properties it always has, and then a Dictionary<string, object> for all the other variable list of values.

You'll need to do some work on the client to bind to this dictionary, not impossible, but a bit messy, as all the way up/down the entire stack, including UI controls/bindings, are optimized for statically defined types.

@Pat
There is no standard way, and Silverlight doesn't have the same extensibility mechanisms that would let you virtualize types/associated metadata etc. as you can on the desktop framework. I'd definitely urge you to go suggest/vote for features such as TypeDescriptor on the Silverlight user voice forum. Hearing from customers with scenarios like yours will help justify and make the case for implementing those features in Silverlight.

One possibility is using reflection emit on the client to generate types on the fly, but its a fair amount of work involved.