[stringtemplate-interest] Data model vs View model

[Zenaan Harkness]

Here are the concepts we work with:

M = data/inputs model
V = view
C = controller

The view, of necessity, must access some data and output its output.

The view in most cases will require more than a single long list of
strings (even though that's what it ultimately evaluates to).

So, the View, to a greater or lesser degree, has a dependence on the
"View Model".

We can then see that the Controller is essentially a transform operator
which transforms a given Data Model into a required View Model.

Next, the question of separation of concerns becomes one of where to
place complexity.

Eg. we consider that views are more likely to change over time
(dang marketing department), and so we use a view generation system
(ST) which enforces a minimal complexity level on the View Model,
thereby limiting the ability for the Controller to intertwine the
Data Model with the View Model.

We can say that it is really only in simpler cases, where the view
closely maps to the Data Model, that the Data Model can be used by
the view as its View Model.

So what are we trying to discourage?

We want to discourage changes to the Data Model which are made simply
to facilitate a specific view requirement.

We want the various Models to be focussed on their domain.

But we also want to reuse that which we can. If the beans in a data
model can (as they can with ST) be used almost directly by the view,
this saves an unnecessary transformation to some 'arbitrarily new'
view model.

Things that are the same should stay the same.

We now return to the pieces of our puzzle:

* Application Data:
  Types, simple or aggregate.
  Is transformed by data loading functionality (eg. read data from yaml
  file, SQL statements sucking data from RDBMS) which transforms the
  Application Data from its source (eg file or RDBMS) into an Application
  Data Model (eg. Collections, Java beans etc).

* Application Data Model:
  Traditionally the "M" in MVC.
  The chosen storage form of the Application Data, for use by the
  Application.  Eg jyaml's resultant java.util.Collections, java beans
  sucked from sql db, etc.


* View Output Data:
  Resultant output of View Templates applied to View Input Data.

* View Data Model:
  Dependency of View Templates; created/ tweaked by controller.
  May or may not be the same as the Application Data Model.
  May have components of the Application Data Model wrapped in wrappers,
  for the convenience or necessity of the View Templates (depending on
  the limitations/ restrictions imposed by the Template transformation/
  View Output Data generation software (ST)).
  May of course be a complete transformation of the Application Data
  Model, which transformation is produced by the controller.

* View Input Data:
  Data stored in View Data Model, and fed to View Templates to produce
  View Output Data.
  Presumably a transformation of the Application Data [Model].

* View Templates:
  What we generally think of nowadays as the "V" in MVC.
  ST templates/ groups; .


* Template Engine:
  StringTemplate; used by Controller to transform View Input Data and
  View Templates into View Output Data; applies View Templates to View
  Input Data to generate View Output Data.


* Controller:
  The "C" in MVC.
  Transforms the Application Data Model into the View Data Model, then
  feeds the View Data Model created, along with the View Templates, into
  the Template Engine (ST) and finally triggers generation of the View
  Output Data.


So, to spell out a hopefully useful point, there are three 'primary'
transformations:
1) Application Data -> Application Data Model
   This is loading data into memory.

2) Application Data Model -> View Data Model

3) {View Data Model, View Templates} -> View Output Data


We could also say that we have Application Data External (on disk, in SQL
DB), and Application Data Internal (that data inside an instance of the
Application Data Model). The question is which distinctions are useful
for dealing with our problem domain(s)...

I guess really at each storage point, data exists, and has a model.
Eg:

* Data chain:
  on disk -> in memory (application) -> in memory (view) -> view output

* Model chain:
  disk model -> application model -> view model -> output model

* Data Transformation Chain:
  load data -> application model to view model -> view model to output

(Is it useful to also speak of a Model Transformation Chain?)


It seems we actually have quite complex systems here...


Principles (please add to list of course):

* Model Stability
  We want to minimize changes to each model, over the long term.
  This minimizes system maintenance cost.
  Keeping view-specific model concepts in the View Data Model, minimizes
  changes to the Application Data Model.

* Model Reuse
  Where it makes sense, we should be able to reuse classes/ beans in the
  Application Data Model as well as in the View Data Model, where it
  makes sense.

* Separation of Concerns
  Ideally, we don't go adding special cases to one model's
  implementation, just to compensate for limitations in another part of
  the system.
  Eg. adding getRandom-attributeTitlecaps methods to the Application
  Model, in order to compensate for limitations of the view transform
  system/ View Data Model.
  We want our Application Data Model, ideally, to stay focussed on being
  just an Application Data Model, and not also being a View Data Model.
  This suggests (liberal?) addition of formatting functions to the view
  system, in order to keep a clean Application Data Model.
  We want the View Model to be separate from View Templates as well;
  this allows multiple output transformations of the same view model;
  eg. from input data to SQL Table Construction statements, and
  from input data to JavaBean classes (for each table).

* Division of Complexity
  There are certain things that need to be done in a system, eg.
  capitalization of strings, conditional view generation.
  The question is one of a tradeoff of complexity in one location for
  complexity in another. Keep the Template Engine simpler, and you push
  some complexity either into the View Data Model or even (for the lazy
  programmer) into the Application Data Model.
  The flip side of the tradeoff is the lazy programmer, given too much
  power in the view to access the model(s), either placing view
  generation logic into the view (which should possibly remain in the
  View Data Model/ Controller, in order to be view/ output agnostic) or,
  even worse, accessing the Application Data Model and possibly even
  producing side effects in the application as a result.
  

One conclusion it seems reasonable to me to make is that limitations in
the Template Engine may encourage the programmer to violate separation of
concerns by embedding custom view logic into the Application Data Model.
The maintenance savvy programmer will go the extra mile to avoid such
incestuousness, but the deadline pressed programmer may not :)


Hope this is useful
Zen

-- 
Free Australia - www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.