Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently setting up a MongoDB database for a web-app. I'm running node.js and using Mongoose to help manage mapping, validation ect.

I'm wondering if it's a good idea to really decouple MongoDB from my code, just on the off-chance we want to switch to something like CouchDB a little later. Specifically, I'd make a databaseManger module that is responsible for setting up Mongoose/Mongo, defining the mongoose models, managing replica sets, and doing some extra validation. This manager would export a generic API, and handle the details of the queries internally. The manager would then be passed around via dependency injection.

Does this make sense? Or am I kind-of redoing some of the mongoose functionality?

Any advice is appreciated.

share|improve this question
    
Will doing this now give you a better design now? Because if not you're doing work now for maybe-benefit in the future. –  Daenyth Jul 24 '13 at 16:58
    
Well the other big plus is that it gives me a place to do all the initialization of schemas, connecting to the database, and setting up the replica sets –  Colin Martell Jul 24 '13 at 17:04
    
@Daenyth maybe its a better idea just to have a module that does all the initialization, then exports the mongoose object? –  Colin Martell Jul 24 '13 at 17:09
add comment

2 Answers 2

up vote 2 down vote accepted

I always try and abstract out data access out of my application code. In node.js, I create repositories for managing data access to any top-level item (aggregate-root, in DDD terms).

Those repositories expose a very clean domain-friendly API to the application, which hides any implementation detail - such as whether it uses MySQL or MongoDB as a back-end. It also converts the raw database-returned data, into a proper domain object.

In a more traditional language, some of those methods would look like this (let's use an ad repository as an example):

Ad #find(id)
Ad[] #findAll()
Ad[] #findByVendor(vendor)

Or, more asynchronously:

#find(id, cb)
#findAll(cb)

Those callbacks should accept err, and then the constructed domain object(s) as the second data parameter.

Also, try and avoid just having basic CRUD interactions, instead try to expose things that actually have meaning in your application.

The other added benefit is that your application code is all much easier to test in isolation, because it's not talking to MongoDB or Mongoose directly.

share|improve this answer
    
Ya that's the benefits I was looking for. Do you mind elaborating a tiny bit on these repositories? I don't quite understand –  Colin Martell Jul 24 '13 at 17:32
    
Look into "Domain Driven Design". Here's a decent intro - net.tutsplus.com/tutorials/domain-driven-design - –  Adrian Schneider Jul 24 '13 at 17:58
    
Ah, didn't know that's what DDD stood for. Thanks! –  Colin Martell Jul 24 '13 at 18:05
add comment

In addition to the accepted answer, you may be interested in looking at some of uncle bob martin's talks about clean architecture. There are several on YouTube for example.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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