I read this in a book:

Most of the time, calls to third-party products are entangled throughout the code. But if you really abstracted the idea of a database out—to the point where it simply provides persistence as a service—then you have the flexibility to change horses in midstream.

Could you please explain to me in plain English (or by example) what does the idea written above in bold mean?


I quoted the paragraph above from a book called: The Pragmatic Programmer on page 60. The more appropriate tag for my question is reversibility but it is not available.

  • 1
    what book do you refer to?
    – gnat
    Feb 20 '17 at 9:13
  • Thank you for the feedback. I quoted that text from the book which title is: The pragmatic programmer page 60 Feb 20 '17 at 9:14

<Something> as a service usually means that an application programmer can forget about an aspect of component of the system they are programming entirely. For instance, "platform as a service" means that you pay a cloud provider money, and they provide you with a ready-to-use running machine with no questions asked - you never again have to worry about security patches, server location, electricity cost or anything else that is usually necessary in order to maintain an array of machines usable for your purposes.

Analogously, "persistence as a service" would mean that storing things to database and retrieving them is handled completely transparently. Ideally, you would create objects in your business domain and simply expect that they are still available and up to date the next time your code runs, without ever programming explicit calls to EntityManager.persist() or Transaction.commit() or any of the "plumbing" code that is usually necessary to achieve this.

I'm uncertain how closely this ideal can actually be approached, but it would certainly be very nice to have.

  • hmm given the "abstracted out" part, I'm not sure that's exactly what the book meant. I'd read it merely that if you abstracted calls for particular database implementations out, you'd end up with a persistence api in your code (like Persistence.storeMyHorses(horses)), that would hide all the implementation details and you could exchange the persistence implementation at a whim. so you would have to still do some call, but it would be abstract and not change if you change your DB completely. Do I misread your answer or do you have insight in the book to get to your understanding? Nov 7 '20 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.