Skip to content
This is a prototyping Rails project for showing different Repository mapping strategies
JavaScript Ruby
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
app
config
db
doc
features
lib
log
presentation
public
script
test
.gitignore
Gemfile
Gemfile.lock
README
Rakefile
config.ru

README

1. What is this?

This is a quick blog in Rails thrown together to show off the benefits of
abstracting out your persistence layer.

This is a very quick app to show some of the concepts I lined out in my blog
"Abstract Persistence Logic" here: http://jasonroelofs.com/2012/07/13/abstract_persistence_logic/

The code found in here is shown in [these slides] from BarCampGR 2012 [link].


2. So what am I looking at?

This is a simple Rails app that does one thing very differently: it completely
separates model logic from persistence handling. You'll see in BlogsController
and PostsController BlogRepository and PostRepository objects. These repository
objects are pointers to the actual repository implementations in use (defined in
config/initializers/repository_mapping.rb).

You can find the current repository implementations in app/repositories. The currently
implemented repositories are:

  1) InMemory: Everything is kept in memory. This is used by the tests

  2) ActiveRecordRepos: Full ActiveRecord implementation, currently backed by sqlite3

  3) YamlRepos: InMemory variant where all changes are persisted into YAML files under db/yaml

You can run the app under any of these using the REPOSITORY environment variable:

REPOSITORY=active_record for ActiveRecord

REPOSITORY=yaml for YAML serialization

Anything else, or leaving REPOSITORY alone will default to InMemory.


3. Other implementation paradigms

If you look at the hidden_persistence branch you'll see the repository object usage moved
into the domain models themselves, leaving the Rails controllers looking a lot like
you're used to, but under the hood we still have the swappable persistence layer
from the master branch. No changes were required in the tests and they all passed.

Once you have a nice abstraction layer for your persistence, where it lives and how the
underneath is implemented is immaterial to your app.

SRP is awesome. Objects should have one and only one reason to change.
Something went wrong with that request. Please try again.