ADO.NET Data Services

ADO.NET Data Services – what waits for us in the future

Sergey Zwezdin — Sat, 12 Sep 2009 11:30:44 GMT

Approximately hardly there is more than year back we have seen a new services platform - ADO.NET Data Services. Its occurrence has marked the beginning of wide use of the REST-approach by many developers. At that time this platform was represented as the convenient tool for access to data through HTTP.

Lately it is possible to understand, that this tool is really successful - huge number of developers have started to use immediately it in the projects. The reason for it is quite logical - use of ADO.NET Data Services allows to cut down expenses on realisation of the most typical scenarios at work with services. It does not mean that SOAP-services and WCF have left in the past, however, in scenarios of the data access preference began to give to ADO.NET Data Services.

In spite of the fact that this platform had some defects at work in non-standard situations, its realisation was enough successful. Therefore among developers there could be a wrong impression that development of ADO.NET Data Services has stopped. It is wrong. Here I will tell that we should see in new versions of this product.

As is known in RTM status now is ADO.NET Data Services 1.0. Subsequently in plans there is a release of version 1.5 which will be a part of .NET 4.0 and Visual Studio 2010. At present version 1.5 is in CTP2 state.

That is interesting, the further direction of development of the project got out proceeding from comments which went from developers community. Thus, version 1.5 will be focused on closer integration with WPF/Silverlight applications, will expand possibilities on executing of server queries and will allow to use even more conveniently services at the client side.

New possibilities of ADO.NET Data Services 1.5 it is much more and we will discuss them with you in the near future. And now I wish to make the small review of that we should see in the new version.

One of weak places of ADO.NET Data Services at present is that in some scenarios we are compelled to load superfluous quantity of data on the client. For example, if the entity contains 40 fields at the access to a corresponding collection we are compelled to load 40 fields all these. At present for such situations it is offered to split entity into smaller and to work with them separately, and for the main query to generate representation with association. However, all it creates additional problems by working out. Other even more unpleasant problem is in case of need to receive quantity of objects in a collection we are compelled to load all collection entirely and already on the client to consider quantity of objects. In new version of ADO.NET Data Services the special attention is paid to these problems. Now we can query projections of any data, and not just entirely all entity. There was a new operator $count which will allow to receive quantity of entities in a collection.
As for an application programming even more often use platforms WPF and Silverlight in new version ADO.NET Data Services the special attention is paid to data binding. This mechanism is successfully enough applied in WPF/Silverlight projects and declarative binding with data became already habitual approach to working out. In the new version all entities which are generated on the client will implement INotifyPropertyChanged interface, thanks to what begins possible to carry out declarative binding with service data.
Also in the new version of a considered platform the attention is paid to work with binary large objects (BLOB), for example, with images. Also fields will be allocated in a special way in metadata and to be loaded on the client side only if necessary.
Interaction with other platforms. In spite of the fact that services ADO.NET Data Services are based on open standards, for work with these services, for example, from Java it is necessary to parse answers from service and to generate queries manually. For simplification of this problem within version 1.5 the mechanism of change of appearance of the answer is implemented (feed customization). Besides, client libraries for work with services ADO.NET Data Services, for example, PHP Toolkit for ADO.NET Data Services which we certainly also will consider already have started to appear.

Thus, the general tendencies and directions are visible to where project ADO.NET Data Services moves and that we should expect from it in the near future.

In the near future we will talk in more details about each of possibilities of ADO.NET Data Services v.1.5, and now I wish to wish you successes in construction of your distributed applications!

Updating data into ADO.NET Data Services which based on LINQ to SQL

Sergey Zwezdin — Mon, 23 Mar 2009 14:43:00 GMT

We continue to investigate possibilites of use LINQ to SQL as model of data for ADO.NET Data Services. Today we will talk about possibility of change data.

I will remind, that ADO.NET Data Services platform gives us possibility not only to select data through web service, but also to update them using methods POST/PUT/MERGE/DELETE. Within data model it is necessary to implement IQueryable interface (for each entity set) for data selecting, and IUpdatable (for datacontext class) for updating.

Let’s go back to LINQ to SQL. If we will try to create LINQ to SQL data model, give access to them via ADO.NET Data Services and try to update data we will find out, that web service generates an error. At superficial studing of a cause of error it is possible to guess, that the problem consists that LINQ to SQL data model do not implement IUpdatable. The reasons of such outcome are obvious: IUpdatable interface is component of ADO.NET Data Services. LINQ to SQL has been released much earlier, than ADO.NET Data Services. Thus it is possible to make a conclusion - implement yet not ready interface LINQ to SQL team could not.

Nevertheless. this restriction really serious and can essentially affect the final solution. Of course, it is possible to refuse to use LINQ to SQL, but it not our method :) How to solve this problem? It is very simple – implement IUpdatable interface manually :)

However, when we see IUpdatable interface it is possible to become despondent, because there it is necessary to implement 12 method with opaque logic.

partial class NewsDataContext : IUpdatable

    #region IUpdatable Members

    public void AddReferenceToCollection(object targetResource, string propertyName, object resourceToBeAdded)

        throw new System.NotImplementedException();

    public void ClearChanges()

        throw new System.NotImplementedException();

    public object CreateResource(string containerName, string fullTypeName)

        throw new System.NotImplementedException();

    public void DeleteResource(object targetResource)

        throw new System.NotImplementedException();

    public object GetResource(System.Linq.IQueryable query, string fullTypeName)

        throw new System.NotImplementedException();

    public object GetValue(object targetResource, string propertyName)

        throw new System.NotImplementedException();

    public void RemoveReferenceFromCollection(object targetResource, string propertyName, object resourceToBeRemoved)

        throw new System.NotImplementedException();

    public object ResetResource(object resource)

        throw new System.NotImplementedException();

    public object ResolveResource(object resource)

        throw new System.NotImplementedException();

    public void SaveChanges()

        throw new System.NotImplementedException();

    public void SetReference(object targetResource, string propertyName, object propertyValue)

        throw new System.NotImplementedException();

    public void SetValue(object targetResource, string propertyName, object propertyValue)

        throw new System.NotImplementedException();

    #endregion

I will not consider details of implementing of each method. These methods will seem to you simple when you look at them in details. That you could use now already possibility of data updating through web service (based on LINQ to SQL model) I offer you one of variants of implementation of the given interface. You can download it (and use in your projects) by using link at the end of this post.

Important remark. As you see, the interface is implemented in a partial-class. It is essential, because if you implement it in autogenerated file “*.designer.cs” you can lose this code at any data model change.

IUpdatable implementation:

DataContext.Updatable.cs

Debugging ADO.NET Data Services

Sergey Zwezdin — Fri, 20 Mar 2009 03:14:20 GMT

Interest to ADO.NET Data Services platform obviously is growing up among developers of web-services. It also confirmed when I receive e-mail letters with questions about different problems. As a rule these questions are reduced to serivce error after some actions, when serivce say about general error and not takes details. In this case services say that he stored information about error in logs.

Whether familiarly to you the given message? I think yes, if you had time to try ADO.NET Data Services in practice.

Really, ADO.NET Data Service not write any messages to log. If you need this behavior you should do it manually. What to do if you need to understand native problem of error?

It’s very simple! You need to go to static method InitializeService,which initiate web-service. In this method passed parameter contains object which implements IDataServiceConfiguration.Last has property UseVerboseErrors. To get more information about error you should set this property to True.

public static void InitializeService(IDataServiceConfiguration config)

    config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);

    config.UseVerboseErrors = true;

Now we call web-service again and we see error details.

Here we can already see some details and even Stack Trace! Often this information is enough. But in some cases this information has not enough. After simple operations in a reflector it is possible to understand, that all ADO.NET Data Services infrastructure is constructed over Windows Communcation Foundation, and is concrete WCF REST API. As you know, in the security goals WCF by default hides exception details. Though, we can override this behavior and explicit specify to WCF that he should show this information. In our case it more simply use ServiceBehavior attribute.

[ServiceBehavior(IncludeExceptionDetailInFaults = true)]

public class WebDataService1 : DataService<MvcMiniCmsEntities>

    //...

Now WCF infrastructure will be include exception details in response and you can understand why error is appears.