Why Data as a Service isn't a Bad Idea

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.