WCF Data Services consuming data from EF based repository

We have an existing repository which is based on EF4 / POCO and is working well.开发者_开发问答 We want to add a service layer using WCF Data Services and looking for some best practice advice.

So far we have developed a class which has a IQueryable property and the getter triggers the repository 'get all users' method. The problem so far have been two-fold:

1) It required us to decorate the ID field of the poco object to tell data service what field was the id. This now means that our POCO object is not 'pure'.

2) It cannot figure out the relationships between the objects (which is obvious i guess).

I've now stopped this approach and i'm thinking that maybe we should expose the OBjectContext from the repository and use more 'automatic' functionality of EF.

Has anybody got any advice or examples of using the repository pattern with WCF Data Services ?

I guess it's a matter of being pragmatic. Does decorating the POCO break anything else? If not, perhaps it's the best way to do it.

WCF Data Services and oData are pretty new, I've also been looking for guidance and it seems a bit thin.

Can you expand a bit more on what you want to expose, and who'll be using it?

The issues I've seen so far in our project

• Having an MyRepository : Objectcontext and a MyDataService : DataService splits logic, so we've created helpers. I suppose we could have inherited Repository though - (literally just thought of that as I typed this!)
• Query and Change Interceptors are your friends, but should delegate to helpers (or base class) to ensure DRY. ie - if your repository already had GetAllUsers, and does logic that myservice.svc/Users doesn't handle, you may need to implement a query interceptor to do the filtering - again DRY means a helper (or base method) that both the repository and interceptor can use.
• asp.net compatibility allows you to tap in nicely to authentication / authorisation - in a query interceptor, it's a nice way to ensure you're allowed to see only the things you're allowed to see.

A couple of traps....

1. If it's Flash / Flex based you will probably have issues with Flash / Flex not being able to use HTTP PUT/MERGE or DELETE. You get around this by using x-httpmethod-override

2. If it's javascript / jquery, make sure you turn on json

Overall, I really like it, a super fast way to expose an API, and provided you don't have heavy business logic, it works well.