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:
Take a look at the XyzDataSource troubles that exist now.
And Stiiiff responded:
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.