CODEWITHSUNDEEP
entity-frameworkodatawcf-data-services
Vaccano
Vaccano

Reputation: 82301

How can I setup OData and EF with out coupling to my database structure?

I really like OData (WCF Data Services). In past projects I have coded up so many Web-Services just to allow different ways to read my data.

OData gives great flexibility for the clients to have the data as they need it.

However, in a discussion today, a co-worker pointed out that how we are doing OData is little more than giving the client application a connection to the database.

Here is how we are setting up our WCF Data Service (Note: this is the traditional way)

  1. Create an Entity Framework (E)F Data Model of our database
  2. Publish that model with WCF Data Services
  3. Add Security to the OData feed
    (This is where it is better than a direct connection to the SQL Server)

My co-worker (correctly) pointed out that all our clients will be coupled to the database now. (If a table or column is refactored then the clients will have to change too)

EF offers a bit of flexibility on how your data is presented and could be used to hide some minor database changes that don't affect the client apps. But I have found it to be quite limited. (See this post for an example) I have found that the POCO templates (while nice for allowing separation of the model and the entities) also does not offer very much flexibility.

So, the question: What do I tell my co-worker? How do I setup my WCF Data Services so they are using business oriented contracts (like they would be if every read operation used a standard WCF Soap based service)?

Just to be clear, let me ask this a different way. How can I decouple EF from WCF Data Services. I am fine to make up my own contracts and use AutoMapper to convert between them. But I would like to not go directly from EF to OData.

NOTE: I still want to use EF as my ORM. Rolling my own ORM is not really a solution...

Upvotes: 2

Views: 1368

Answers (4)

Vagif Abilov
Vagif Abilov

Reputation: 9991

You have some other options for your OData client. Have a look at Simple.OData.Client, described in this article: http://www.codeproject.com/Articles/686240/reasons-to-consume-OData-feeds-using-Simple-ODa

And in case you are familiar with Simple.Data microORM, there is an OData adapter for it: https://github.com/simplefx/Simple.OData/wiki

UPDATE. My recommendations go for client choice while your question is about setting up your server side. Then of course they are not what you are asking. I will leave however my answer so you aware of client alternatives.

Upvotes: 0

Suneet Nangia
Suneet Nangia

Reputation: 1670

Apart from achieving more granular data authorisation (based of certain field values etc) OData also allows your data to be accessible via open standards like JSON/Xml over Http using OAuth. This is very useful for the web/mobile applications. Now you could create a web service to expose your data but that will warrant a change every time your client needs change in the data requirements (e.g. extra fields needed) whereas OData allows this via OData queries. In a big enterprise this is also useful for designing security at infrastructure level as it will only allow the text based (http) calls which can be inspected/verified for security threats via network firewalls'.

Upvotes: 0

Ladislav Mrnka
Ladislav Mrnka

Reputation: 364259

If you use your custom classes instead of using classes generated directly by EF you will also change a provide for WCF Data Services. It means you will no more pass EF context as generic parameter to DataService base class. This will be OK if you have read only services but once you expect any data modifications from clients you will have a lot of work to do.

Data services based on EF context supports data modifications. All other data services use reflection provider which is read only by default until you implement IUpdatable on your custom "service context class".

Data services are technology for creating quickly services exposing your data. They are coupled with their context and it is responsibility of the context to provide abstraction. If you want to make quick and easy services you are dependent on features supported by EF mapping. You can make some abstractions in EDMX, you can make projections (DefiningQuery, QueryView) etc. but all these features have some limitations (for example projections are readonly unless you use stored procedures for modifications).

Data services are not the same as providing connection to database. There is one very big difference - connection to database will ensure only access and execution permissions but it will not ensure data security. WCF Data Services offer data security because you can create interceptors which will add filters to queries to retrieve only data the user is allowed to see or check if he is allowed to modify the data. That is the difference you can tell your colleague.

In case of abstraction - do you want a quick easy solution or not? You can inject abstraction layer between service and ORM but you need to implement mentioned method and you have to test it.

Upvotes: 3

TomTom
TomTom

Reputation: 62093

Most simple approach:

DO NOT PUBLISH YOUR TABLES ;)

  • Make a separate schema
  • Add views to this
  • Put those views to EF and publish them.

The views are decoupled from the tables and thus can be simplified and refactored separately.

Standard approach, also for reporting.

Upvotes: 1

Related Questions