Models: two very different concepts

Question

There are a lot of questions and answers about what a/the model is. Particularly when discussing where business logic belongs and the MVC pattern. There seem to be two concepts that need to be severed. I hope a question to this specific clarification has value.

The options are:

1. A simple data carrier. No thinking except maybe some basic validation. (eg. POJOs/POCOs, View Models, classes mapped to database tables) (eg. here and here).
2. An entire layer (or even group of layers) that comprise all business logic and data access (eg. here, here and here. A model can be almost anything).

The term model seems to have suffered beyond recovery. People are changing their architecture without realizing that the term is ambiguous.

Perhaps the perfect example of this ambiguity is Microsoft's architectural diagram of MVC: The MVC pattern is clearly located in the UI layer, but the concept of a model clearly spans every layer.

This is very confusing for both new comers and experienced software engineers.

I would like to point out that option 2 does not correspond in any way to the definitions of the word model. That does not help.

My questions are:

1. Have I missed something important or does this accurately describe what has happened to the term model?
2. Considering option 2 is unintuitive, don't we have better words for these different layers (like services, repositories, etc.)?

Answer 1

One issue with these discussions is the all-to-frequent mixing of different architectural viewpoints in the same discussion or diagram.

• Some architectural viewpoints are meant to show depth: deep dives into how some particular functionality is implemented.
• Whereas other architectural viewpoints are intended to show breadth: the interactions of components that are peers (that exist at the same level in terms of depth).

Mixing both viewpoints (depth and breadth) together in the same diagram tends to lead to confusion.  In surveying the sources your citing, I find no shortage of this kind of mixing of these what would more ideally be separated architectural viewpoints.

For example, the diagram you're showing (citing Microsoft), you have said MS claims to be an MVC diagram, but it is primarily showing depth in the domain model, with overweight focus on persistence (from the MVC perspective). So, this diagram is weak on the breadth viewpoint of interacting peers (M,V,C) and mixes in some depth viewpoints with persistence: broken out (and elevated to be a peer of the other components).  It is understandable that one might question where the domain-logic belongs given the-all-to-easy-to-mix architectural viewpoints.

In MVC, the model is what is responsible for maintaining domain objects, responding to domain-oriented queries & commands (including validation, etc..), and enforcing/effecting domain-oriented rules & behaviors.  MVC doesn't speak to breaking out persistence: if your system includes persistence that is an implementation detail (detail of depth, not of breadth).  Thus, there is no question as to where domain-logic belongs in MVC, or whether domain-objects should be dumb or smart — these questions are all internal aspects (implementation details) of the model.

---

You are also correct that the term Model is overloaded and over used.  So, what the term means has to be evaluated in some context.  Unfortunately, many of these discussions fail to set or keep context, adding to confusion.

In MVC, the term Model means what I mentioned above (keeper of domain objects, handler of queries & commands..).  We might speak of POJO's, and such discussion should apply to the interactions between the peers M,V,C, and whether the query & command interface to the model uses dumber or smarter objects.

In detailing persistence — an implementation detail from the MVC perspective — we can speak to POJO's, or smart/dumb at different places in the persistence mechanism, we can even reuse the term model at different interfaces in the implementation details of persistence.

In summary, it is possible for the term model to be used in both ways you're describing — it is not either/or.  What makes things confusing is that we often fail to set context, and/or fail to show when we're shifting context from breadth (interacting of peer components) to depth (implementation detail of usually of one of these component).

Answer 2

In MVC, the Model is anything that is not part of the View or the Controller. In MVVM, the Model is anything that is not part of the View or the ViewModel. That should be easy enough to remember.

If that definition doesn't satisfy you, then think of the Model as all of those components that relate directly to your problem domain, such as a Customer class or an Invoice class. Everything else is part of a UI abstraction, which is all MVC and MVVM really is.

In other words, MVC and MVVM really have nothing to say about the Model, from an architectural perspective. The structure and organization of the Model is entirely up to you; MVC and MVVM concern themselves primarily with the other components (view, view model, controller).

Further Reading
Domain model from Wikipedia

Answer 3

The model is not "everything else". The model is the number behind 3.14159... It is not "3.14159265". It is not the button you push to get pi. It is not the paper you write π on. It is not the blinking lights you use to communicate the ratio of a circles circumference to its diameter. It's the number, however you choose to model that, that you use when calculating other fun stuff like waves, rolling tires, and rotated text.

Now sure, half tau is just a dumb constant that you can pull out of a library but the point is you have to decide how you model things based on your modeling needs. This is how your application thinks of the world. That's what a model is. How to show, manipulate, remember, communicate, or any other thing besides modeling is not the models job.

You can put business rules in the model. But those rules had better be about modeling something. Not anything else.

If following these rules means you have no where to put something fine. Make somewhere new to keep it. You will make an ungodly mess if you blindly follow prepackaged designs rather the pay attention to what your problem is telling you that you need.

Answer 4

In clarifying the term Model, let us start with the definitions in Trygve Reenskaug's original notes on the MVC concept written in 1979.

A Model is an active representation of an abstraction in the form of data in a computing system.
Thing-Model-View-Editor

Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.
Models-Views-Controllers

In the comments following the definition of a Model in the first paper, Reenskaug gives an outline of how the Model should be represented in a computer.

The models are represented ... as a collection of data together with the methods necessary to process these data.
Ideally, all models should be totally consistent.
Thing-Model-View-Editor

Reenskaug appears to be defining two concepts with a single word. Models are both an abstraction to be represented in the computer and also a representation of an abstraction. A distinction needs to be made between these: the Model as an abstraction and the Model as a representation of that abstraction.

Another description is offered by Steve Burbeck in his paper providing information essential for new Smalltalk-80 programmers.

[T]he model manages the behavior and data of the application domain
How to use Model-View-Controller

which also considers the Model as an active representation.

In 1980 a paper by Ted Codd was first published. In it a Data Model is defined as...

...a combination of three components:

1. a collection of data structure types (the building blocks of any database that conforms to the model);
2. a collection of operators or inferencing rules, which can be applied to any valid instances of the data types listed in (1), to retrieve or derive data from any parts of those structures in any combinations desired;
3. a collection of general integrity rules, which implicitly or explicitly define the set of consistent database states or changes of state or both.

Data Models in Database Management

Chris Date has also defined a Data Model as...

...an abstract, self-contained, logical definition of the objects, operators, and so forth, that together constitute the abstract machine with which users interact. The objects allow us to model the structure of data. The operators allow us to model its behavior.
An Introduction to Database Systems (Eighth Edition)

In these definitions a Data Model is a formal abstraction. The components match with those Reenskaug states should comprise the Model to be represented in the computer. Therefore, it is concluded that a Model as an abstraction is a Data Model.

A DBMS implements a Data Model. It allows users to create a structure of object types; create or use a predefined collection of operators to process that data; and declare and/or implement constraints to ensure the data is consistent. Therefore, it is concluded that the Model as a representation of an abstraction - i.e. the Model component of a MVC framework - is a DBMS.

Answer 5

Let's take a step back.

Regardless all the other distracting definitions of the word, in technology a model is a workable picture of a problem, an analogy, something that allows you to communicate about a creation. There may be many models to the same thing that all make sense. And one model may work for more than one thing. Like a tree with a stem and branches is a model that works for a lot of technical stuff.

In software modeling, the model is most often an unspecified part of the system. It is unspecified because it is different for each application. And therefore confusing. You have your database (pretty concrete, who doesn't have one?), you have your UI (alright, I know what that is), and then you have something in between that is up to you do define and work out, that is the core of your application, that makes your application different from other applications that follow the same design principles. That would be your "model".

Answer 6

As far as your questions:

1. I do feel that you are missing something with both of the provided concepts on models.

2. In certain cases, those other names are not necessarily at the same level as model, but they can be things part of the model.

That is not to say that there are instances where the distinctions you see just don't happen.

I have a few things that I try to keep in perspective when approaching some kind of model.

From the model itself:

• what should I (the model) know about myself?

  • something like should I know my position if I make up a list of things, or should I know the items/formula/constraint used to define my exposed value

From anything that calls the model:

• Do I provide the results of a formula/constraint to the model, or should I be agnostic of how the result was determined?

  • something like position (x & y, or some group of containers) to determine some value or derived rule that the model doesn't need to parse/determine

So, there are cases where different pieces of business logic is in a place that they don't belong, but that really depends on the overall intent of some app or domain which can still change over time.

For the concept of better names, the reason for stating whether something like service or repository is not necessarily on the same level is for the same reasoning stated above.

• As a service, is my result something that is used to be the model, or am I used to derive some other value associated to the model?