This project is read-only.


Proper support for Complex Types


(see also: )

The current preferred approach for this is to in-line the complex type - equivalent to if it had been eagerly loaded - but with no self link.

However, this development is dependent upon the RO spec formally defining the structure for in-lined objects.
Closed May 9, 2013 at 4:44 PM by RichardPawson


RichardPawson wrote Feb 1, 2013 at 2:28 PM

It might be possible to deal with this in a manner equivalent to the AddressableViewModels, where the complex type would have its own Oid that, somehow, incorporated the identity of the 'root' object.

I can see an easy way to do this for a simple case, but it would break down if - as commonly happens - you have complex types that are shared by several different root classes (Address, or Name being obvious examples) and/or where a root has more than one property of the same complex type.

RichardPawson wrote Apr 29, 2013 at 3:09 PM

Further to my previous comment...

For the cases where more than one root class needs to share the same complex type (e.g. Customer#Address and Supplier#Address) and/or where one root object has more than one property of the same complex type (e.g. Order#BillingAddress and Order#ShippingAddress) then the simplest way to do this would be to make each complex type unique, but to inherit from an abstract superclass that provided all the common logic/behaviour e.g.:
public class OrderBillingAddress: Address 
public class OrderShippingAddress: Address
public class CustomerAddress: Address
Taking the first example, the BillingAddress property would contain a link to an object with e.g. this Oid:
This would be created and interpreted by the server, using a mechanism similar (or identical) to the addressable view model pattern, whereby this means 'OrderBillingAddress for Order with Id 1'.