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...

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.

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.

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.

Sure, I believe you, and you understand abstraction too.

Great, I hope you have a competent architect.

Did you even bother to read the article you linked to? LOL. It clearly states that it oxidizes several metals. It then goes on to describe the reaction that you're trying to claim is the only oxidation case. In fact, the article you linked lists at least four chemical oxidations above and beyond those involving metals.

You seem to only capable of reading about the ones that have to do with water. Rather selective of you.

Don't let basic reading skills stand in your way of looking silly [sic].

Yes, you can. The article you linked points this out to you as well.

You appear to be obsessed with the colloquial definition of 'oxidize.' You should check out the formal definition; especially the part that relates it entirely to electron transfer.

See the stupid people who agree with me:

http://www.chemguide.co.uk/ino...

Don't just read the first part (the beginners' definition), read down to the "most important use of the terms oxidation" part...

Maybe I should have typed that in all caps so you could read it...

I guess those electrochemists who study high pressure oxygen plasmas are a bunch of idiots...

Yes, I'm guilty of very loosely (as in 'incorrectly') using the term combustion to describe the visual equivalent. I thought it would save me some time, it did not. ;)

Running shoes sounds 'optimistic' ;)...

Using the term combustion was shortcut to avoiding discussing the details of highly oxygenated plasmas. BTW, oxygen plasmas are yellow, much like flames...

You mean like Chlorine trifluoride? Lol...

Funny, just a few years ago I was the chief software architect for a company purchased for more than 60 million dollars entirely for our enterprise product. One of the primary reason this company was acquired instead of its competitors was because we were pioneering open standards in our market verticals and supporting those open standards with public integration points that 3rd party companies, including our competitors, wrote integrations to.

This system had a persistence model that had to scale, not just horizontally, but in 'swim lane' fashion - or if you prefer the actual fashion we used, in AKF cube fashion. It handled tens of millions of persisted logic events daily and integrated with many different back end databases - all supported through this EXACT same facade/proxy system implemented with adapters. This pattern was used for all of the integration points and was how 3rd parties wrote integrations with our system.

So, whatever it is you do, you can rest assured that I write enterprise software in the "real world" and quite successfully.

You really just can't seem to understand abstraction.

Not at all. Again you demonstrate that you don't understand what abstraction is. By hiding the details of the persistence model, which means (so that you understand) that people using the abstraction interface don't know if it is a DB, or a file, or a web service, or a pipe, or a local process, or a remote process, the business logic simple deals with business objects.

If I was talking about abstracting the "business level" (presumably you mean business logic) I would be talking about an interface exposed to a view or consumer that didn't need to know any details about how the business logic operated. I was clearly not talking about that at all.

I'm willing to bet that you end up in a lot of 'arguments' where you bring out this line. It's okay, maybe some day you'll get it.

Well, in the real world, when you abstract things properly you don't expose a "connect" method. The code behind your interface - the adapter - would use connect and disconnect internally.

In the real world, when you abstract things, you expose a method that validates that the persistence layer is functioning/configured/usable as a normal part of the application/service/component's life-cycle. I called it ValidateConnection in this scenario because of the way he described his issue.

No, you don't, there are plenty of things that burn without oxygen simply because there are lots of other oxidizers. Oxygen just happens to be the most common.

In any case, the combustion being referred to isn't "burning" it is the light emitted by the compressed gasses, and with oxygen being much more exciteable than nitrogen and their being the two most prevalent gases in this scenario, that's what I was referring to. This is what you see from a 'flame' in any case.

"...so that you simply write an adapter for pushing/pulling data" makes you think the abstraction layer would have the DB layout in?

Let me be perfectly clear then, the abstraction layer would simply know about the business logic side of things and that you can store and retrieve those things in some fashion most likely represented by some criteria associated with them.

I don't know what you mean.

What? Who/what would already "have a connection" to another server or memory mapped file or process or socket?

ValidateConnection, in this example, would simply ensure that the backend persistence mechanism both exists and (as is required in most cases) that you have valid credentials.

Why would you be modeling anything relating to entities at the interface level?

iMyDatabase would have methods such as:

ValidateConnection
GetSomething
StoreSomething

It shouldn't know anything about how that data is stored, where it is stored, how your object is serialized/deserialized from a DB entity, et cetera...

The nitrogen under pressure remains inert, but the oxygen will combust at those levels. There's a great video of the plastic block they were testing with years ago with a huge wall of flame behind it as it traveled at mach 5 iirc...

I would have to agree about PostgreSQL, it is surprisingly flexible and powerful. I've used it for small business systems and recently on a 'big data' (oh, that overused buzzword...) project (millions of devices reporting dozens of times per day) and it has been fantastic.

Wish I'd gotten on the bandwagon 10 years ago.

...so that you simply write an adapter for pushing/pulling data.

Then you don't have to worry so much about making what appears to be an extremely premature optimization.

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.

Later, when you find out that you actually do need MongoDB, PostgreSQL, sharded MariaDB, whatever, you can simply write another adapter class that simply has to satisfy the iMyDBAdapter interface.

The reason this works so well is that it will force you to separate your business logic from your underlying DB implementation (which requires a lot of discipline to do otherwise, especially when you just want to get something 'done'.)

Also, as another poster pointed out, you're much more likely to suffer from other issues relating to scaling (and issues better solved elsewhere) than a modern database.

My advice, stick rigidly to the interface/adapter mechanism and implement an adapter for whichever DB you're most comfortable with right now.