views:

196

answers:

1

I have been getting into RIA services because I thought it would simplify dealing with the services layer of web applications I wish to build. I see lots of examples out there showing how to create DomainService classes which expose and consume entities that have some kind of relational database backing, and therefore have foreign-key relationships. However, I would like to know how to expose and consume normal object graphs...objects that contain references to eachother but don't have foreign keys.

For example, say I want a service operation called "GetFolderInformation(string pathToFolder)". I want this to return a custom object called "FolderInformation" structured with:

 - string Name
 - IEnumerable<FileInformation> Files

I cannot get this to work because it seems that RIA wants to deal with entities that have foreign key relationships. Why? Why can't the serializer just see my object references and recreate that in the proxy on the other side?

Data exists behind service layers that doesn't necessarily have foreign key relationships...like folder/file for example.

EDIT: I realized I hadn't asked my question! My question is, is there a way to do what I am trying to do?

A: 

This (complex types, object graphs that aren't about entity associations) is something we want, but didn't make the cut for v1.

This is because there is a lot more than seralization to handle, which is perhaps the simplest part of the scenario. More involved is code-gen'ing client types that support change notification, tracking, undo, etc. etc.

There are ways to workaround. Generally involves flattening on the boundary and recreating a graph on the other side from flattened set of data. It's not necessarily straightforward in app code, even though techically possible.

NikhilK
I'm sure it is much more complex than I am making it, but why can't normal object graphs be treated just like entity graphs by using something like ObjectId in place of an explicit [Key] attribute when the [Key] attribute has not been defined?
Mike Gates
The key exists to allow stitching partial object graphs across sessions, and requests... as such using an Object reference (assuming that is what you mean by ObjectId) doesn't work. You need the first object that is referring to the second object know what is the key to the second object without even having a reference to it, i.e. a foreign key. And as such the idea is second object needs to have a stable and unique key.
NikhilK
I'll take your word for it there. Thanks!
Mike Gates