
MVC is just sloppy thinking – prove me wrong - fallingfrog
This is MVC - as I understand it.<p>Model<p>The model is the System - all of the relationships, and all the data at a given time.  Now in scientific terms a Model is something that exists in the mind of an observer - it is a set of equations or rules that we use to understand what forms a system can take and what the constraints on a system look like.  But here we are using the term &quot;Model&quot; to mean both the relationships between data, <i>and</i> the data itself.<p>View and Controller<p>Here sources say different things about what parts of, say, a web page are in the &quot;Controller&quot; and which are in the &quot;View&quot;  Some say that the view is the CSS, the model is the HTML, and the controller is the web browser.  Some say that the model is the database, the view is html and css and javascript, and the controller is all the code that makes decisions about how to save and retrieve data on both the client and server side.  But generally it appears that the View and Controller taken together form the boundary to the system- the GUI and API.  In particular it appears that the Controller is the layer of API functions that exist to facilitate user interaction with the Model, and a View is something generated at a particular time by the Controller to be displayed to a specific user.<p>--But!  I&#x27;m also seeing people say that the Controller can be created by the View, (what??) or that the Model can be stored on the client side.  I&#x27;m also seeing various options for whether the Model or the Controller &quot;does persistence&quot;.<p>Searching the web has only lead a stronger and stronger sense that the reason I don&#x27;t understand Model-View-Controller is that nobody else understands it either, or really agrees on what those terms mean.  Prove me wrong, and I&#x27;ll be forever grateful!
======
ADanFromCanada
You are both overcomplicating it and under-estimating the complexity of these
systems. Your main problem is scope. When you say "But generally it appears
that the View and Controller taken together form the boundary to the system-
the GUI and API.", it tells me that you've got a fundamental misunderstanding.

So, scope:

You should be thinking in the context of JUST your API, or JUST your GUI. And
even within your GUI, you should think about JUST a single component.

Now, a complex application can be thought of as multiple components (a menu; a
calendar; a list of projects; a profile) within a component (web page;
dashboard; profile) within a component (web app) within a system.

So, scoped down to the ACTUAL piece of the system you're working on; think of
the definitions like this:

MODEL - This is your data, according to the DOMAIN in which you're working.

VIEW - This is the visual representation of your data.

CONTROLLER - This is the code that contains the BUSINESS LOGIC that gets your
data, changes your data, evaluates your data, changes your view, executes an
algorithm, hits your API, etc.

These concepts come from Object Oriented Programming... the basic premise of
which is to build objects that can be re-used in different components of the
system. Sometimes it makes sense, sometimes it doesn't. Also important to
understand in this world is the concept of SINGLE RESPONSIBILITY ... that is,
in most cases, it is ideal to limit the functionality of any given piece of
any given component to a specific and clear task/responsibiility.

So:

You have a MODEL object because if the concept of a "Project" is used in
multiple components of a persistent application then you'll want to be able to
create an instance of a "Project" and pass it around to be re-used. This way,
you and your colleagues can be sure that "Projects" are always defined the
same way, with the same properties, and an actual instance of a given project
can be shared, transferred, altered, etc. in the same way by any part of the
system.

The concept of Views really only applies to GUIs where you need to show
something in a visual way. It's really this simple.

And the reason you have a controller is because the natural question you
should be asking yourself at this point, considering single responsibility,
is: Okay, I have my DATA and I have my means of VISUALIZING it, so how do I
tell my visualization which data to visualize?

And that in a nutshell is the responsibility of the controller. Get, hold,
manipulate, use, the data. Put it in the view. Hook into events in the view
and change the data accordingly. Hit the API to save the data when
appropriate. Modify the view to confirm the success to the user. etc. etc. But
the ACTUAL data itself, the actual class or object that describes the fields
that make it up, THAT is what your Model is.

Hope this helps clarify things... many more examples are warranted I'm sure.
But you really should read a book on the subject. The internet is not a great
place to really learn anything.

~~~
fallingfrog
Ohhkay. I think I start to see what you mean- in other words MVC is not
supposed to describe an _architecture_ in the sense of database-client or
something like that but just a _style_ where we attempt to separate concerns
into business logic vs UI. And we encapsulate data in the classic object-
oriented way where we always try to access the data through a set of functions
which are written ideally so that no matter what inputs the functions get the
data is never allowed to be in an inconsistent state, and the business logic
goes in that layer so that the data never violates business rules / rules of
accounting/ etc.

~~~
ADanFromCanada
Replace "style" with "pattern" and "written" with "logically grouped together
and written" and you've nailed it.

Very impressive interpretation and summarization of what I wrote!

