Friday, April 16, 2010

The WCF Data Services Toolkit mess

Related to custom data providers for WCF Data Services I am just looking at the Data Service Provider toolkit and I notice several things.

1.) You obviously need tons of glue code to expose the most simple classes like.

public Class B
{
public string NoIdProperty {get;set;}
}

public Class A
{
public B MyB { get;set; }
public int MyIDProperty { get; set; }
}

2.) The whole System.Data.Services.Providers Namespace is as good as undocumented. At what point in time/in which order the fuctions in IDataServiceQueryProvider are called? Only reverse engineering or many breakpoints/stepping through will tell you.

3.) The whole namespace smells like entity framework to me (e.g. looking at the ResourceTypeKind enum).

4.) The whole data services error reporting/debugging is not even close to real life requirements. I definitely need more details that just "Something blew up somewhere". I need something like the WCF tracing facilities before I can ever think about getting a Data Service into a production environment.

5.) The toolkit code is a mess.
I only looked at the RO examples, but just looking at the typed and untyped examples you find many differences in the glue code. They do really questionable things like storing their own ResourceTypeAnnotions types in the CustomState properties of the that is obviously needed to store a missing link from the ResourceTypeRessourceTypes to the RessourceSets.
They do really messy things like in GetQueryRootForResourceSet(ResourceSet) function (typed/ro example) that are all but intuitive.
They need a whole bunch of helper and extensions classes (glue), only to make your own interfaces somehow usable.

In short: the Custom Data Service Providers interface feels like it was not designed for what we are trying to do here.

I really love the idea of WCF Data Services that expose objects, because they close a significant gap in current data access architecture.

Maybe I did not get the concept of custom data service providers or I am just too stupid, but so far it looks the current ADO .NET Data Service implementation will never match my expectations.

Maybe Microsoft should consider dumping the current implementation and start a rewrite that is designed for exposing objects over WCF, instead of just entity framework over HTTP. Trying to fix the current code seems to be a big waste of their and my time. But at least Microsoft should do their homework in regards to documentation before thinking about extensions.

No comments: