CODEWITHSUNDEEP
odatawcf-data-services
Vaccano
Vaccano

Reputation: 82517

OData on top of 2+ OData Feeds

Say I have the following model

Two OData Feeds from two databases

I would like to present a unified front for these OData feeds to my clients.

Is there a nice way with OData to do this? Or should I just take IQueryables from the OData feeds and make a reflection endpoint on top of these?

If I use the reflection stuff on top of the OData that talks to the database (via Entity Framework) what kind of problems am I going to encounter?

Upvotes: 2

Views: 320

Answers (2)

Chris Schaller
Chris Schaller

Reputation: 16757

Not happy with the current accepted answer for this question, for me it's more of an anti-answer, of what not to do. My solution here applies as much today as it did in '11

To support a tenancy scenario, where each user/client data will always reside on the same Database, and the data schemas all match then all you need to do is change the connection string when the data context is instantiated.

Another term for this concept is Sharding, MS have some tools and APIs that can help, This is a simple enough walkthrough: Azure SQL Database Elastic database tools: Shard Elasticity but you can do this pretty easily from first principals.

If swapping out the connection string will work for your scenario we need to identify the mechanism that you will use to determine the connection string, there are two common solutions to this:

  1. The simple way out is to use fixed host headers, a route or token in each request to the service, then you can hardcode the logic for determining the connection string without complicated mapping logic.

  2. Use a master / header / mapping DB to store your configuration.

    This database has a separate schema that's primary purpose is for retrieving the correct connection string for each request. In most cases we combine this with the Authentication process, in which case you keep the authentication in this central database, not in the individual databases.

In terms of the OData Controller, even with WCF Data Services, you just need to implement your logic for retrieving the connection string and use that when you instantiate your data context.

Of course, this doesn't help you if your client's data is spread across multiple databases, but it is a pretty common pattern for sclaing out large databases withough having to deploy a new farm of services for each database.

Upvotes: 0

Vitek Karas MSFT
Vitek Karas MSFT

Reputation: 13320

I would not use the reflection provider over the client library, mainly because the client library LINQ provider doesn't support all the constructs used by the server. As a result some queries would simply not work at all (projections and expansions usually get broken). Assuming you don't want to create any associations between the databases, you should be able to simply point the users at the right service. You can still expose something which looks like a unified endpoint without the need of having the same URL for all of them.

The main idea is that you unify the $metadata (if your model is static you can do this manually, if not you should be able to write some kind of "merge" tool pretty easily) and then provide a service document which points to the respective URLs for each entity set. In the WCF Data Services client, there's now support for these kind of services through entity set resolver: http://blogs.msdn.com/b/astoriateam/archive/2010/11/29/entity-set-resolver.aspx The latest CTP with that support is here: http://blogs.msdn.com/b/astoriateam/archive/2011/06/30/announcing-wcf-data-services-june-2011-ctp-for-net4-amp-sl4.aspx

Upvotes: 2

Related Questions