MVC is just sloppy thinking – prove me wrong
4 コメント
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.
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.
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.
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!
Very impressive interpretation and summarization of what I wrote!
Thank you for helping out!
Model
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 "Model" to mean both the relationships between data, and the data itself.
View and Controller
Here sources say different things about what parts of, say, a web page are in the "Controller" and which are in the "View" 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.
--But! I'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'm also seeing various options for whether the Model or the Controller "does persistence".
Searching the web has only lead a stronger and stronger sense that the reason I don'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'll be forever grateful!