Database Calls vs In-Memory Objects – How and When to Update

Architectureclass-designjavascriptnode.jsobject-oriented

I'm creating an app in javascript/nodejs and using neo4j as database.

Let's say I have an entity User in my database. It has a bunch of properties, like boxes_collected and places_visited, which keep updating independently of one another throughout the course of running my app.

So far I have functions that talk to the database to update these properties directly. But it's getting a bit messy and I'm thinking of making a single high level object/class that handles everything in a much cleaner, nicer, and eloquent way.

Here's a tiny version of my "model" to better explain what I mean:

Suppose I have a function like this

function UpdateUserValue_plants(number) {// update database}

But then if were to create a User object and incorporate the above into it,

var User = function User(plants, other...) {
    this.plants= plants;
}

User.prototype.updateValue_plants = function(number) {
    this.plants += number; // first update the model itself
}

Then when am I supposed to update the database? And wouldn't I be doing the updatation twice that way: first the object's property, then the database?

Is there an elegant solution to this?

Best Answer

One approach is to come up with some way of tracking your changes, then dumping them to the database in bulk. There are different approaches to this, but you will need to have something keep track of all the original values, then figure out what has changed, then batch that up into inserts, updates, and deletes.

Martin Fowler calls the object that keeps track of this a Unit of Work. This object handles CRUD for all the business objects. From the link, it should be clear that you use registerNew, registerDirty, registerClean, registerDeleted from within properties setters, and use rollback or commit when you are ready to save everything.

There is discussion of pros and cons of various implementation details in Patterns of Enterprise Application Architecture as well. Some things to think about are how often to hit the database, what to do if clients are engaged in a business transaction longer than your database transaction can feasibly be, and whether to talk to your Unit of Work via events or directly.

This functionality will be part of what an ORM does best, and if you can find one it will be better than writing one. But understanding the concepts would still be valuable.

Related Topic