+972 52-548-6969
The database as a service anti pattern
time to read 2 min | 210 words
A while ago I stated:
The problem is supporting change tracking in disconnected scenarios. In particular, you take an object from the database and send it to the presentation layer, some time later, you get the object from the presentation layer and persist it to the database again. There is a whole host of bad practices and really bad design decisions that are implicit in the problem statement, but we will leave that alone for now.
I was asked what I meant by that. I think that just the title of this post should suffice as an answer, but I believe that I can let Arnon answer this best:
So why is exposing the database through a web-service (RESTful or otherwise) is 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
Comments
The first idea I got from your post is that you're contradicting yourself somehow. You said some time ago that Microsoft Entity Framework's support for disconnected data objects is broken. Today you say that directly exposing data objects through external interfaces is a bad practice. So the conclusion is:
Microsoft EF is broken because it doesn't properly support disconnected data. But that's good because disconnected DAOs are evil. :) So EF is not broken - it's just idiot proof :)
RafalG,
The scenario is discouraged from design point of view.
It is useful in cases, and anyway persistence framework should not affect how you design things.
Hi,
Sometime ago I started to make a small scale test of putting the domain objects in a ASP.NET MVC app and using Rails to access them using a REST, and it worked, but it was just a spike to learn more about routing.
But this post makes me wonder, it's OK to expose domain objects? If the services are protected inside a controlled network, not meant to be public at all, it's still considered bad design? Do you have any suggestions to make this two worlds talk?
Thanks a lot.
It also opens up some nasty scenarios with concurrency. With the database exposed as a service, you have to look at how you are going to manage transactions across the service boundary. Either that or tell your service consumers that data loss will result from interleaved read/writes.
How is applying a service endpoint to a relational database different than directly using an XML database such as eXist? I realize you probably wouldn't favor an XML database given this post, but it tends to more easily lend itself to OOP persistence. Certainly, Evan's points related to transactions are important, but using a Unit of Work pattern could relieve that problem.
I really like this approach as it seems to ease the object-relational impedance mismatch. Well... almost.
Comment preview