Why the Database as a Service is a Bad Idea
Microsoft recently released SP1 for .NET. While the SP brings some nice stuff, it seems it also has some bugs and a few less than inspiring components.
Another
example for a less than stellar idea is the "ADO.NET data services"
component. Before I go on to explain why I think that, I should
probably mention that this isn't just a Microsoft thing as IBM also mentions similar ideas as part of their (broader and sometimes even worse) view of "Information as a Service".
So why is exposing the database through a web-service (RESTful or otherwise) wrong? Let me count the ways:
- It circumvents the whole idea about "Services" - there's no business logic
- It makes for CRUD resources/services
- It is exposing internal database structure or data rather than a thought-out contract
- It encourages bypassing real services and going straight to their data
- It creates a blob service (the data source)
- It encourages minuscule demi-serices (the multiple "interfaces" of said blob) that disregard few of the fallacies of distributed computing
- It is just client-server in sheep's clothing
When it comes for ADO.NET data services you can add a few other problems like:
- it isn't really RESTful - you can also "enhance" the services with operations like example 18 in "Using ADO.NET data services" : http://host/vdir/northwind.svc/CustomersByCity?city=London (though it does support caching and hypermedia ). Not being only RESTful is not a bad thing in itself. It is the inconsistency of the API when the reson de etre of the service is exposing data
- Also (on not being RESTful) it doesn't really externalize a state machine it externalizes a relational model
- It is built on Entity Services.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






