Matthieu MEZIL : ADO.NET Data Services Hooking POC

ADO.NET Data Services Hooking POC V4

Matthieu MEZIL — Mon, 27 Oct 2008 23:38:00 GMT

I don't like rights management with ADO.NET Data Services.

Indeed, you can use a method with ChangeInterceptor attribute to manage CUD operations and a QueryInterceptor attribute to manage Read operations. But if it's a right logic, I think it should be in the entity class (in the BLL) and not in the service.

With my POC, you just need the entity type implements one or two interfaces:

public interface IEntityNeedRightToRead
{
    bool CanRead(string login);
}
public interface IEntityNeedRightsToWrite
{
    bool CanChange(string login, string propertyName);
    bool CanChangeLinks(string login, string propertyName);
    bool CanAdd(string login);
    bool CanDelete(string login);
}

Moreover, in my sample, I have the Login property in my entity types so it's easy to return the default value of a property if you don't want to expose it for the connected people.

The next step is, in this case, to exclude the property if it is in ETags.

ADO.NET Data Services Hooking POC V3 .1

Matthieu MEZIL — Sun, 19 Oct 2008 06:07:00 GMT

I just finished implementing the IUpdatable interface

With ADO.NET Data Services, in the client part, you can use some LINQ queries which will be translated to an url. It’s really great to be able to use LINQ. However, this query is restrictive. For example, extension methods defined in the Queryable class aren’t allowed with ADO.NET Data Services (NotSupportedException).

When you add a web reference to your service, you will have some entity classes generated from the service metadata. If you have a relationship defined with a List<T>, or IEnumerable<T>, etc., in the server, the client generated code will use a System.Collections.ObjectModel.Collection. This class has a Count property. But when you want to use this on a LINQ query, you have a DataServiceQueryException. My ADO.NET Data Services Hooking POC solves it.

ADO.NET Data Services Hooking POC V3

Matthieu MEZIL — Fri, 17 Oct 2008 15:58:00 GMT

The third version of my ADO.NET Data Services Hooking POC is released.

The IUpdatable interface is partially implemented. I am waiting for an answer to my thread to implement ClearChanges and ResetResource methods.

Note that it’s a POC, so my tests are very primitive. If you find a bug, let me know and please send me a code to reproduce it at matthieu.mezil at winwise.fr.

I will use this post to answer some questions:

Why having a class hierarchy like this for my entities?

EmployeeBase (abstract)
- Employee
- ManagerBase (abstract)
  - Manager
  - TeamManager

With ADO.NET Data Services, you can’t have inheritance between the classes you expose. So if you want to expose some employees and some managers, you can’t have Manager inheriting Employee.

Why defining relationships in the exposed classes and not in the base?

An employee has a Manager property and a Manager has also a Manager property. But if you define the Manager property in EmployeeBase, you have a NullReferenceException when you want to get the metadata. It’s a framework bug which will probably be fixed in next version.

ADO.NET Data Services Hooking POC v2

Matthieu MEZIL — Wed, 08 Oct 2008 08:23:00 GMT

I continue my POC development.

In my previous version, I didn't supported keys in url. I do now. So I can do something like this:

http://localhost:50683/WebDataService.svc/Teams(guid'adbae845-989e-4aae-8273-0b4325556812')/Employees

I hope this POC will become more than a POC. ADO.NET Data Services has some limitations with EF:

EF limitations
ADO.NET Data Services use the metadata, so if you add some properties on your entity types or on your context, ADO.NET Data Services ignore them
the "bug" which forbids relationships on children classes

My POC tries to resolve these problems.

The next version will probably implement the IUpdatable interface to allow data updates.

ADO.NET Data Services Hooking POC

Matthieu MEZIL — Sun, 05 Oct 2008 16:59:00 GMT

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.