M is for Model

The (first and lead) M of MSDCPVMUI is for “model”.  I use model more or less with the same intent that the term is used in other M-ish patterns like MVC, MVP, MVVM, etc.  The Wikipedia article for MVC has a decent enough starting point description for model in this regard, so I can avoid writing chapters about it in my current context.

In constructing abstract models for representation in an automated system, I sometimes distinguish between two directionally different modes of model interactions:  modeling to describe, and modeling to proscribe.  Representational modeling focuses on describing something or sets of things (and possibly their possible transformations) into a consistent contextual space.  Teleological modeling attempts to project a consistent contextual space into specific answers to targeting questions, or into courses of actions to achieve specific goals.

The first is the domain of science (such as, describing the flow of a river), the second is the domain of engineering (such as, designing a bridge to span a river).  I won’t pretend that my view is authoritative or that it is my definitive idea on the subject of models.  Just sort of roll with the basic directionality of constructing a contextual space abstracting “real things” into model elements, or constructing a contextual space pushing model elements to drive external effects.

If I had a major reason for describing things as I did in the following two paragraphs, it is to imply that what a model encompasses should be constrained mainly by what you choose to represent and what you desire to achieve; boxed in naturally by your available resources.  When it comes to developing automated systems that follow an operating model such as MSDCPVMUI, the idea of partitioning models becomes important for a variety of complexity limiting reasons.

Without trying to categorically model the classification of model partitioning right now, I’ll give some examples of partitioning:

• business functional partitioning: insurance claim, loan document, training material
• common abstraction partitioning: specific document versus generic document management structure, functionality subscriber versus customer profile
• operational partitioning: document management versus process flow control
• “framework components“: security principal identity, authentication, persistence, service location, presentation, customization, synchronization, notification

Some things stand alone, some are built on top of other things, some things operate on other things, and some things make sure everything stays within, or has access to, a well-defined (distributed) operating environment.

Concretizing Abstract Models

So far, I’ve kept it fairly abstract.  But for a distributed system pattern like MSDCPVMUI, the components need to be represented in a distributed system environment.  I’ll rely on my areas of experience to confine myself to a range of representations that run the gamut between pure-object systems through pure relational database systems.  Ikosa is a “pure-object” system in that the canonical model representation is .NET object class instances.  My professional experience has ranged more in pure-relational to semi-relational systems; including systems that do model-centric processing in objects and use databases for persistence, and systems that do heavy model-centric processing in a database runtime.

Since I’m mostly concerned with Ikosa, I’ll be approaching most topics from an object-oriented perspective.  Keep in mind that conceptually, the same basic topics can map into the relational database model as well, but the actual implementations including relative complexity and operation performance costs for things may be different (and have different names).

Lifetime and Persistence

Persistence is the ability for the model to exist outside of a particular runtime session (or environment).  For the Ikosa system, this is handled by packing all the object instances away when done using them, or backing up the object graph after changes to hedge against a runtime crash (or even when desiring an UNDO).  I go more into the actual persistence mechanisms used in the Ikosa framework here.  Individual model elements (i.e., class instances) might be created and destroyed between “saves”, however truly ephemeral model elements are not referenced by any other model element except in the call context of an executing operation.

Business systems I work with typically handle persistence using relational databases; immediately maintaining a virtually immortal and location-less state of the model (in most cases a semi-relational data model).  I’ve worked with systems that are highly stored procedure based, as well as highly ORM-based systems (and hybrids built with one grafted to the other, where the SPROC side SPROCs and the ORM side ORMs).  My preference is to use an ORM such as Entity Framework and keeping all the transaction control under oversight of the implementing service while committing whichever DbDataContext instance might hold aspects of the models.

Integrity

The model element is it’s own last line of defense against invalid state changes demanded of it from outside the model itself.  If the Ikosa framework used a relational database storage engine, it could use referential integrity at the database layer as a hard super last line of defense, but it does not.  The running object graph is the model for the Ikosa framework.

Within a model element proper, various model integrity strategies are employed, but most of them comes down to not exposing read-write state without having functional setters or procedural methods that perform validation-like functions on the desired properties or method.  Most “bad” data pushed against model changes is simply ignored; and results checked after setting.  This is sort of necessary as it is possible to intend to make a change, but something in the model state actively resists such a change.  For instance, a player might try to move a piece of furniture, involving all the mechanics of the action, effort, time and targeting, but be prevented by character maximum load, not enough movement, or a magical or mundane effect holding the furniture in place.

Some things that “fail” to affect a desired change might generate notifications which I’ll mention more under the service article.

Service-level validation in Ikosa exists to make sure that all parameters match to actions or targets in the model before letting the model system process them.  (More on that later also).