Why Data As A Service Isn't A Bad Idea

Early this week I encountered the post "Why the Database as a Service is a Bad Idea" written by Arnon Rotem-Gal-Oz in DZone. The title caught my eye and I read the post. I must say that there are a lot of things that I agree with the author and there are some things that I think should be considered again and will be explained in this post.

Why Not to Use Database as a Service?

As the author wrote the exposing of a database internals through a service is not a good idea at all. Services are meant to be an operational contract between the service consumer and the service provider. Also, the use of database as a service encourages bypassing real services and going straight to their data.

Why to Use Data as a Service?

Even so, I must disagree about the potential of ADO.NET data services when it's understood. I think that with the examples that Microsoft (or others) gave to the use of the technology they shot themselves in the leg and I'll explain why. To expose data through a service isn't such a bad idea. To expose database through a service is a bad idea. Microsoft's operation regarding data services can be metaphoric to walking
on very slippery rocks. The examples that were showed by Microsoft people of how to expose an entire database with full CRUD operations through data services made them slip. Such a thing is not a good practice at all even with the security data services provide. On the other hand using a custom LINQ provider to expose data is a more reasonable thing to do. The provider will help to expose relevant data (doesn’t necessarily have to be database) which the application need. You can look at an example of using a custom LINQ provider in a previous post I wrote. Using the provider way doesn’t expose your database to the world and helps you expose and consume the entities that you need in your application.

The Potential of ADO.NET Data Services

So what is the potential of ADO.NET data services? In a RIA applications or data driven application it can help to provide a cleaner solution. The ability of data services to return responses in JSON or in URI makes
them flexible and usable by Ajax or Silverlight. Also, if the data service is consumed by a .Net client you can use the LINQ to data service feature. The data services come with other features like concurrency, batch operations over HTTP, full query operation support and more. These features, when used right, can help to provide good solutions for a data driven application.

Conclusion

Lets sum up the post, first I must indicate that I’m not a Microsoft employee and the opinion written here is my own. I think that some things that were written by Arnon in his post are right but even so the technology has a very good potential which was explored earlier.

The thing about a new technology is what to do with it. What you are going to do with ADO.NET data services will determine it's future. I really don't think that you should use it to expose your entire database. I really do think that you should use it to expose data as a service.

Gil Fink is working at Sela Group as a .NET consultant. Gil graduated his computer science BA degree in the Interdisciplinary Center in Israel with honours. Also, Gil holds a Microsoft's MCPD enterprise application developer title. Gil's fun is to develop infrastructure for projects, solve logic and design problems and to return home to his baby boy Oron and his loving wife Liora. Gil's interests includes variety of things including Enterprise Library, WCF, LINQ, Entity Framework or whatever Microsoft is throwing at him. Gil is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website.