Every once in a while when something hits you, you really remember it; it stands out in your mind as an "Aha" moment. One of those moments for me was when I saw a particular "Model/View/Controller" (MVC) diagram, and the light bulb went on. This diagram made the MVC pattern very simple, and I've never forgotten it.
The diagram I'm talking about comes in two parts. The first MVC diagram is very simple, and shows the symbols the authors used for Model, View, and Controller objects. Here's that diagram:
When drawing UML diagrams, the authors use these symbols instead of generic UML symbols -- a practice I first learned when using Rational Rose -- and it really helps to improve the readability and usefulness of UML diagrams.
The second MVC diagram was the one that really turned on the light bulb for me. The column on the left side of this MVC diagram shows the operations that are allowed according to MVC rules, and the column on the rights shows the "bad" behaviors -- methods of communication in your classes that should not happen. Here's the diagram:
Personally, I just ignore the column on the right, and focus solely on the column on the left, but initially the right column may make the rules more clear.
The left-side column of this diagram states the following MVC pattern rules:
If you understand these rules and commit them to memory, I think you'll see that the MVC concept becomes very simple.
I've found that whenever I start to take a shortcut, and do something like connecting to View objects together in my programs, a little alarm starts going off in my brain, and that alarm is directly related to this diagram and these rules.
This terrific MVC diagram comes from the book, Use Case Driven Object Modeling with UML : A Practical Approach . If you've never used the Unified Modeling Language (UML) on a software project, I highly recommend this book. In fact, I recommend it so much that I used to give it away when I was teaching object-oriented programming and UML. While their techniques would probably be considered a little too "heavy" for most developers these days, if you have no other process going at all, I recommend starting with the process they describe, and trimming it down to what works for you.
As a final note, you can probably tell that I doctored the two MVC images above. That's because the authors use a slightly different terminology than MVC. Instead of saying Model, View, and Controller, they refer to these object types as Entity, Boundary, and Control objects (Model is Entity, View is Boundary, and Controller is Control). I'm not sure where that terminology comes from -- it strikes me as something I saw in Rational Rose a long time ago -- but the meaning is the same.