And it is distributed objects all over again
time to read 3 min | 506 words

I just got a comment on my previous post, which included this statement. This is important enough for a post. We are basically talking about abstract the persistance layer completely. My thoughts about that are:

There is a big disparity between the various persistence approaches. Considering that Microsoft isn't really known for working with the community to provide a provider model that can satisfy even the 80% of the common ground, I just don't see it happening.
Take a look at the XyzDataSource troubles that exist now.

And Stiiiff responded:

I don't want to know that I am querying a 'database'. I want to retrieve data and save data. I don't care where they come from, where they are stored, neither how they are stored. This should be up to the configuration and providers' implementation. I want the Persistence Layer to manage local or distributed transactions 'transparently' if the data comes from one or more datasource(s).

This is really the wrong way to go, in my opinion. It seems like recently I am hammering on the issue of leaky abstractions, but this is important. What Stiiiff suggest is a leaky abstraction by defination. There is a world of difference about the tradeoffs that I need to do for local and remote transactions, for working over hierarchical data stores vs. relational ones vs flat ones. You really do care if a transaction is executing over a remote database and the response time suddenly grows by two orders of magnitude.

What you would end up in this cases is that you would have to really understand the provider that you are using, and exploit the provider specific features to be able to meet your requirements. This basically completely defeat the whole point of having a provider model in the first place. If I really need to know everything about both the underlying implementation and how the provider behave with respect to it, just to be able to do my work, I am in a losing situation.

I would much rather code directly against the underlying implementation. I wouldn't have to understand the provider in this case.

Just look at the whole fiasco about transperant distributed objects "Yes, you can just change the configuration and suddenly the user.Name property is executed on another machine, no code changes required." Except that there are code and design changes required, and I want the API to reflect that, rather than give me an opaque surface that I would have to dig into to do my job.

 

Tweet Share Share 6 comments