ADO.NET Data Services - what awaits us in the future

About a little over a year ago we saw a new then platform for building services - ADO.NET Data Services. Its appearance marked the beginning of the widespread use of the REST approach by a large number of developers. Then this platform was presented as a convenient tool for accessing data through the HTTP protocol.

Since that time, we can already understand that this tool is really successful - a huge number of developers started using it immediately in their projects. The reason for this is quite logical - using ADO.NET Data Services allows you to reduce the cost of implementing the most typical scenarios when working with services. This does not mean that SOAP services and WCF are a thing of the past, however, ADO.NET Data Services began to give preference in data access scenarios.

Despite the fact that this platform had some flaws when working in non-standard situations, its implementation turned out to be quite successful. Therefore, among developers, there could be an incorrect impression that the development of the ADO.NET Data Services project had stopped. This is not true. Here I will talk about what we have to see in the new versions of this product and about where this direction is heading.
')
As it is known, ADO.NET Data Services 1.0 is now in RTM status. Subsequently, plans are to release version 1.5, which will be part of .NET 4.0 and Visual Studio 2010. At the moment, version 1.5 is in the state of CTP2.

Interestingly, the further development direction of the project was chosen on the basis of comments that came from the developer community. Thus, version 1.5 will focus on closer integration with WPF / Silverlight applications, expand the possibilities for server requests and make it even more convenient to use services on the client side.

There are really many new features of ADO.NET Data Services 1.5 and we will discuss them with you in the near future. And now I want to make a small review of what we have to see in the new version.

• One of the weak points of ADO.NET Data Services at the moment is that in some scenarios we have to upload an excess amount of data to the client. For example, if an entity contains 40 fields, then when accessing the corresponding collection, we are forced to load all these 40 fields. At the moment, for such situations it is proposed to split the entities into smaller ones and work with them separately, and for the total sample to generate a presentation with a union. However, all this creates additional problems during development. Another even more unpleasant problem is that, if necessary, to get the number of objects in the collection, we have to load the entire collection as a whole and have to count the number of objects on the client. The new version of ADO.NET Data Services is given special attention to these problems. Now we can choose on the client the projections of any data, and not just the whole entity. For example, using a query, we can select only a few fields and work with them. In addition, a new $ count operator appeared, which will allow you to get the number of entities in the collection.
• Since for building applications, WPF and Silverlight platforms are increasingly used in the new version of ADO.NET Data Services, special attention is paid to the binding of data. This mechanism is quite successfully used in WPF / Silverlight projects, and declarative data binding has become a familiar approach to development. In the new version, all entities that are generated on the client will implement the INotifyPropertyChanged interface, which will make it possible to implement declarative binding with service data.
• Also in the new version of the platform under consideration, attention is paid to working with large data (BLOB), for example, with images. Also, the fields will be highlighted in a special way in the metadata and downloaded to the client side only when necessary. In addition, the forced mode of displaying data in the form of pages will be available. This means that if you have a large enough collection, then it will be given to the user only in parts. We could get the same functionality in the first version when using Take / Skip operators, but when accessing the entire collection, however, all the data was issued, which could lead to an additional load on the server.
• Interaction with other platforms. Despite the fact that ADO.NET Data Services services are built on the basis of open standards, to work with these services, for example, from Java, you need to parse the responses from the service and generate requests manually. To facilitate this task, version 1.5 introduces a mechanism for changing the appearance of the response (feed customization). In addition, client libraries for working with ADO.NET Data Services have already begun to appear, for example, PHP Toolkit for ADO.NET Data Services, which of course we will also look at.

Thus, the main trends and directions are visible where the ADO.NET Data Services project is moving and what we should expect from it in the near future.

Finally, I want to mention that in addition to the fact that ADO.NET Data Services exists as a separate product, it is also used as a basis for other Microsoft technologies. For example, the .NET RIA Services platform, which makes it very convenient to build Silverlight-based RIA applications, very actively uses ADO.NET Data Services to ensure the interaction of the server side and the client. An even more ambitious case is the SQL Azure project, which allows you to place your data in the cloud within the Windows Azure cloud platform. This once again confirms that ADO.NET Data Services is a truly effective and reliable tool that can be trusted with the issues of service interaction.

In the near future we will talk in more detail about each of the features of ADO.NET Data Services v.1.5, and now I want to wish you success in building your distributed applications!