Skip to content

Programming Model: MSOFS Design Pattern

Jump to bottom
ChrisRus edited this page Nov 9, 2013 · 16 revisions

TOC Table of Contents // Back: Introducing ONMjs // Continue: Data Modelling

ONMjs is based on a design pattern called Model-Store-Observe-Feedback-Signal (MSOFS) that borrows and blends concepts from many classic design patterns. The MSOFS moniker is a mnemonic intended to make it easy to remember the architectural structure of ONMjs-powered applications so that you can apply it effortlessly during the design phase of your project.

MSOFS is based on the core principles of:

MSOFS can be used to build Model-View-Controller (MVC), and Model-View-View-Model (MVVM) implementations (or others), but is neither of these patterns; MOSFS has its own specific semantics detailed below.

Model-Store-Observe-Feedback-Signal

Taking each part in turn:

  • Models abstract the schema (i.e. the structure, properties, and addresses) of application-defined data object hierarchies. Models are meta-data used to manage actual application data objects at runtime.

  • Stores store and manage addressable instances of application-specific data objects. The structure, properties, and addresses of application-specific data objects contained within a Store is governed by a Model.

  • Observers are application-specific routines that "observe" and react to changes in the topology and/or properties of application-specific data objects managed by Store(s).

  • Feedback occurs when some application logic (e.g. an Observer, an AJAX request handler, whatever...) mutates application-specific data object(s) managed by a Store.

  • Signalling is an ONMjs-defined protocol that defines the granularity, semantics, and timing of events (i.e. callbacks) dispatched by a Store to Observers indicating that Feedback has occurred.

Stated a little differently, ONMjs provides you with a way to declare and annotate your application's data object model ( Model concept ), an automated way to create, read, update, and delete (CRUD) actual instances of your declared objects ( Store concept ), a set of API's for writing what essentially boil down to event handlers ( Observer concept ), API's for interrogating the Model and interacting with the Store, and a protocol for wiring everything together ( Signal concept ).

See also: TodoMVC, Model-View-Whatever, and MSOFS (blog post)

Separation of Concerns

MSOFS promotes the development of highly modular and decoupled applications via a structured separation of concerns:

  • Meta-data ( Model concept ) is separate from data ( Store concept ).

  • Data ( Store concept ) is separate from application logic ( Observer/Feedback concepts ).

  • Application logic subsystems are decoupled and separated insofar as they interact directly with Models and Stores but never directly with one another.

Applying the MSOFS Pattern

ONMjs is inherently flexible and endeavours to impose rules and conventions only where necessary to proactively steer you towards the goal of decoupling your application subsystems elegantly from one another. For example, ONMjs' data model declaration facilities are powerful enough to allow you to encapsulate your entire application data model in a single large declaration. But you don't have to; if it makes more sense to partition your application's overall data model into smaller chunks you're free to declare as many separate models as you require.

Consequently, MSOFS is not some grand pattern imposed upon an application as if it were some sort of globally appropriate conceptual jig. Rather, the concepts of MSOFS are applied iteratively at the granularity of your model partitioning.

For example, you may find it convenient to codify the data model of some information that's stored in a database separately from the data model that underpins the UI of your application, and use separate ONMjs.Store instances bound to each of these models at run-time. Both subsystems are manifestations of the MSOFS pattern and as such are architecturally similar at a high-level of abstraction despite that fact that semantically they differ quite radically.

TOC Table of Contents // Back: Introducing ONMjs // Continue: Data Modelling

Copyright (C) 2013 Christopher D. Russell

Clone this wiki locally