When you use ADO.NET Data Services, you will reduce the flow between the client and the server to get only the entities you really want. If you use EF with ADO.Net Data Services, you will also reduce the flow between the Server and the DB.
EF (particularly in the first version) doesn’t support all cases. So sometimes, you need to develop your own entity classes which encapsulate your EF ones.
In this case, with ADO.NET Data Services, the flow between the Server and the DB isn’t optimized. I made this POC to do this scenario.
When I did it, I realized that the ADO.NET Data Services Framework is extremely closed and most of classes / interfaces / enums are internal. I think that something will change in V2. For example, you have an internal interface System.Data.Services.Providers.IDataServiceProvider only implemented by System.Data.Services.Providers.BaseServiceProvider which is an internal abstract class. I think in a future version, the interface will be public. Else I don’t understand why the interface is used for.
To be able to hook the normal ADO.NET Data Services way, I have two choices:
· I rewrite a lot of the ADO.NET Data Services internal classes
· I use, by reflection, the Internal classes
The first choice is probably the best one because as the classes are internal, MS can change their members in the future version but, as it’s just a POC, I choose the second choice which is fastest.