| 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. |