A Comment On Prevayler vs. Database

There’s a really interesting debate on Prevayler vs. database usage for storing data going on over here at The Fishbowl: Prevayling Stupidity.
Lots of interesting points are made both for and against and when it is and isn’t appropriate to use an in-memory system like Prevayler, but one comment in particular stood out for me. It was this one:

And even if you have a dedicated machine, you have to wonder what happens if you’re providing some kind of service that gets really popular, really fast. Brad from Livejournal originally wrote the site to host him and a few friends. If he’d written it using Prevayler, it’d have fallen over the moment it got really popular, and today he wouldn’t be running a website with half a million users.

OK, now hidden in that statement is an instance of really bad design. I hope you see it but just in case you don’t, here’s what’s missing. Any application which is storing and retrieving data needs to have abstracted out all of that process into data access objects (DAO). Even if I’m writing something “for my friends” or “just for me” I assume nevertheless that I may someday change how I store and retrieve the data for my program. It may be something like a switch from database to Prevayler or from local storage to access via a web service to a remote server. Either way, because I’ve abstracted out the operations I need to perform I can write those quickly to get something which functions and then tune for performance later or completely replace the whole DAO implementation with another that simply implements the same interface.
So, take this to the bank, never never ever embed your data access in the rest of your application in such a way that you have to change any code in the meat of that application simply to replace something as simple as a persistence mechanism.

2 thoughts on “A Comment On Prevayler vs. Database

  1. Hristo Stoyanov

    I think you are missing the point here …
    A very important concept in OOP is that data is ALWAYS private to the objects and it is accessed thru object’s public interface ONLY. Separation of data from objects (via, let’s say DAO) is a “necessary evil” in the case of RDBMS, where you have to consider the data by itself, a thing with its own life.
    Why don’t you just write a small application that interacts with the Prevayler system and exports the data in whatever form you like it (XML, CVS, DB files, you-name-it). Typically, it
    is only a few lines of code ….

  2. John Munsch

    Nope, I didn’t miss the point. You need to read the DAO pattern I linked to. You’ll notice that the pattern deals with data in the form of objects or at the very least “Value Objects” (yet another pattern). Notice for example that their example CatalogDAO returns Catagory and Page objects from your various requests rather than just data.
    A good DAO is part of the Model in a Model/View/Controller application. It may rest under the Model or for applications that mainly just store and retrieve data the DAO may be the entire Model. Either way there should be additional objects that represent the data that the application as a whole communicates in terms of.
    So, in the case of Live Journal you might have Blogs, Entries, Comments, and Users as fundamental data objects that the system understands. Each with operations which can be performed on them (classic OOP). The DAO layer abstracts out the details of the operations you are likely to perform so you might have a function like this:
    public Collection getMostRecentEntries(Blog blog, int maxEntries)
    This function goes and gets the 5, 10, or however many most recent entries for a given blog and returns them in a collection for you to display on somebody’s weblog homepage. Note that you haven’t violated OOP in any way by using DAO, it’s just an abstraction that keeps you from knowing whether Prevayler is sitting behind the scenes pulling those items off of a LinkedList or Oracle is performing a SQL query and converting the ResultSet into a set of objects it puts into a collection.

Comments are closed.