MVC persistence patterns

There are many different ways of implementing persistence with an MVC framework, each with different trade-offs. When writing Chrome Apps, choose the frameworks with MVC and persistence patterns that feel natural to you and fit your application needs.

The model does its own persistence - ActiveRecord pattern

Popular in both server-side frameworks like Ruby on Rails, and client-side frameworks like Backbone.js andember.js, the ActiveRecord pattern places the responsibility for persistence on the model itself and is typically implemented via JSON API.

A slightly different take from having a model handle the persistence is to introduce a separate concept of Store and Adapter API. Store, Model, and Adapter (in some frameworks it is called Proxy) work for hand by hand. The store is the repository that holds the loaded models, and it also provides functions such as creating, querying and filtering the model instances contained within it.

An adapter, or a proxy, receives the requests from a store and translates them into appropriate actions to take against your persistent data layer (such as JSON API). This is interesting in the modern web app design because you often interact with more than one persistent data layer such as a remote server and browser’s local storage. Chrome Apps provides both Chrome Storage API and HTML 5 fileSystem API for client side storage.

Pros:

• Simple to use and understand.

Cons:

• Hard to test since the persistence layer is ‘baked’ into the object hierarchy.
• Having different objects use different persistent stores is difficult (for example, FileSystem APIs vs indexedDB vs server–side).
• Reusing Model in other applications may create conflicts, such as sharing a single Customer class between two different views, each view wanting to save to different places.

Controller does persistence

In this pattern, the controller holds a reference to both the model and a datastore and is responsible for keeping the model persisted. The controller responds to lifecycle events like Load, Save, Delete, and issues command to the datastore to fetch or update the model.

Pros:

• Easier to test, the controller can be passed a mock datastore to write tests against.
• The same model can be reused with multiple datastores just by constructing controllers with different datastores.

Cons:

• Code can be more complex to maintain.

AppController does persistence

In some patterns, there is a supervising controller responsible for navigating between one MVC and another. The AppController decides, for example, that a ‘Back’ button moves the client from an editing screen (which contains MVC widgets/formats) to a settings screen.

In the AppController pattern, the AppController responds to events and changes the app’s current screen by issuing a call to the datastore to load any models needed and constructing all of the matching views and controllers for that screen.

Pros:

• Moves persistence layer even higher up the stack where it can be easily changed.
• It doesn’t pollute lower-level controllers like a DatePickerController with the need to know about persistence.

Cons:

• Each ‘Page/Screen’ of the app now requires a lot of boilerplate to write or update: Model, View, Controller, AppController.