WCF DS recently (5.0?) introduced the awesome feature of properties being collections of complex objects. This makes great sense for e.g. orders/orderlines and persons/addresses, since each orderline/address is owned by its parent (order/person) and does not need to be an entity. For some backends this enables great performance increase in some scenarios.

The typical theoretical example of using complex types is an Address property of some entity. In the real world an address typically contains a city and/or a country. Although the address is unique, the city and/or county probably would be shared between several entities. Thus we would like to model the city and the country as entities rather than complex types.

But since we are not allowed to have navigation properties on complex types, we can not model the address as having a city and/or country. And then the use case of order/orderlines and persons/addresses fails...

For simple complex properties (not collections) a common workaround would probably be putting the entity references on the owning entity instead of in the complex property. For collections of complex objects this is not an option.

And since complex properties should be nothing more than imposing structure on the entity ("grouping properties"), we should be able to to use the same toolset when constructing the complex types as when constructing the entity types.

A wild guess is that this limitation comes from Entity Framework and relational databases where the complex type is typically mapped to a table and the navigation property would create a foreign key between the complex type table and the referenced entity. When building custom providers, we are not limited to relational databases though. Just guessing...

What do you think?

I've tried to get an answer to the following request in different forums, e.g. http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/c91a5988-3298-4ca8-8688-a6fa4558dcf5, however as this is cross-product line, nobody seems to have a best-practice advice.

Can Microsoft please publish a *working* real-world sample, demonstrating the co-existence of classic WCF, OData and EF code first using a singleton object as the root of an object graph:

- a singleton object is the root of an object graph in memory (let's say: a company, its employees and their computers; two 1:n relations)

- the singleton and its graph is accessed using classic WCF for complicated method calls AND by OData services for access by mobile devices.
OData was meant for easy data access, however it turns out to be the afterburner to reach smartphones. WCF never got that effort... So OData must fullfil where WCF falls short.

- How can a WCF service host and the OData service host access the same singleton object? Obviously only if both communications are hosted in IIS. But I am sure that's not enough...

- because I am a database agnostic programmer, I use EF 4.2 code first on top, as an appendix. So how do I set up EF Code first context class for supporting singleton OData and singleton classic WCF? There is a blog entry which doesn't provide enough info for me:
http://social.msdn.microsoft.com/Forums/en-GB/adodotnetdataservices/thread/a48bb8de-0d2d-4d58-8d41-4cf381390de9

- which methods/constructors are called in what sequence when the service is started? where should the DB be read in? where should the seed data be written in case there is no DB?

- the first question is whether MyEFContext inheriting from DbContext and containing the DbSet properties should be serviced using WCF to the outside world at all. Or if the MyEFContext object should be used for DB I/O only on the side, that means classic WCF and OData services the base object graph to the outside world. The latter looks very good to me, if DB read only happens on service startup and SaveChanges() only on service shutdown.

- the resulting code should be encapsulated in libraries so it can be hosted in a windows service or IIS.

- to make matters more realistic: the objects in the object graph issue events. Those events and their event handlers a) need to be rewired upon reading from the DB and b) events should propagate to the OData clients (smart phones).
I've heard that b) is only possible through Azure using a Windows Phone Notification service. However my company, because of local data protection laws, does not allow to use the cloud.

- And for B**M fans: where and how in classic WCF, Odata and EF can Async be applied for a high-perf server?

I expect many application programmers to start planning and developing this kind of app in 2012. Therefore I ask for such a sample now. I develop software for 35+ years now and this is the best time of my life because of all the new technologies coming out now and saving a lot of „plumbing“ code.

I am willing to create this sample, document and publish it on codeplex, however I need detailed guidance.

Thank you very much!

Have a $metadata only command for a select. This would return the full metadata for a select, but no actual data.

We need the metadata because we then provide the user with what properties they can make use of from a select. When providing that metadata in a prompt, we do not need any data at that point in time.

This should be on the server so that a program written to handle version 3 will still provide the correct metadata if the server is version 4 and the uri passed in uses commands that are new to version 4 and therefore would not be recognized by a client side parser reading the uri and using the EDM to build up the metadata for that uri.

Currently WCF supports access restrictions at the entity level using entity set access rights (and something similar for service operations). It also supports, through query interceptors, the ability to filter rows on a per-request basis. It does not, however, support access restrictions on a per-field basis. It is also quite difficult to add support for this. The only workarounds are non-trivial, especially if you're using entity framework as your provider because WCF custom generates query Expressions specifically for entity framework's IQueryable implementation, differently from custom providers or the reflection provider.

So far, the only workarounds that appear to be feasible are to create custom metadata on a per-user basis. This has performance implications. The other option is to re-parse the query for each request, and throw an exception if the query references properties in the model that the current user is not allowed to access.

I would like the second option - the ability to return an error response when a query would have otherwise referenced a property (either explicitly, via a $select, $orderby, $filter, or $expand query option, or implicitly by accessing a collection or single item without explicitly $selecting fields the user has access to. These restrictions would be evaluated when the request is parsed (including requests contained in a batch request) but before the request is submitted to the server.

Also, I would like to add a second layer of field-level access restrictions - row-specific column restrictions. Example: User A has access to the SSN column for THEIR User record, but not someone ELSE's User record. These restrictions would be applied in a query interceptor after the original query was submitted to the provider and the result was returned. In order to implement this, you could either have a black box of "check that the query that returned this result didn't reference these fields", or else pass the original query to the query interceptor so that it can process it itself (preferably the query should be in the form of an ODataContrib odata query node tree, and not a .net Expression, as the former is far easier to visit than the latter.