Your first post I answered to certailny was not clear about "abstracting away persistanve issues"
Are you an escaped inmate from a Guatemalan insane asylum?
The entire first post, including the title of the post, is explicitly about abstracting your persistence model.
"In other words, have your backend web services (presuming you're using them and not manually POSTing from a socket yourself to your own socket server) instantiate an instance of iMyDBAdapter and use it."
Maybe you don't find that clear, but that's because you apparently don't understand abstraction...
your naming examples like ValidateConnection or CheckConnection are certainly bad choices as an example.
The stupidity of your statement really cannot be overstated. You dislike ValidateConnection because you claim you will simply catch an exception when you connect; ergo, you are either connected or you are not. This, alone, is proof that you do not understand abstraction.
I'm a real programmer, not a manager.
And you'll apparently never get any further, because you'll need to understand abstraction before you can be an architect. I'm also not a programmer, I'm a software engineer (there's a difference that you're not aware of), a software architect, a founder, a co-founder, and I also perform technical due diligences for multiple Vencture Capital firms.
Abstracting away the fact that a Service is remote and not local leads to all forms of problems. It is very often. o good idea.
Actually, this is EXACTLY what you should abstract away. Yet again you demonstrate your lack of basic understanding of the purpose of abstraction. You think that abstracting away 'locality' is bad and leads to problems? Why on earth would it do that? LOL. Your abstraction layer should satisfy the requirements of the business logic, if locality is an issue (i.e. for performance) then your adapter implementation must account for that. The only time anyone using your abstraction layer should ever know anything about locality would be if that knowledge would be required so that the business logic could make a decision - otherwise, that sort of information should be encapsulated totally.
And no, I don't use that line often, actually I don't remember if I had used it already once.
Sure, I believe you, and you understand abstraction too.
Well, the application I'm working on right now...
Great, I hope you have a competent architect.