I think the MVC concept is mostly interpreted as a simple design pattern. But it is a much older (measured in IT eons) concept than a design pattern.
MVC is about separating data and behavior (Model) representations (Views) and user input (Controllers).
It can be applied to command prompt operated programs, batch processed tasks, web apps and GUI's. IMO, the narrow interpretation stems from the use of Observer-Observable-Event implementations of GUI widget libraries (Smalltalk, Java Swing/AWT, MFC, VB,...)
But MVC can be applied as an architectural pattern to. Implement and identify objects that are conceptual, logical parts of the application. That embody state and behavior. They have to make up the top level 'model'. Every view that is implemented must use the same basic Model, and register different listeners/observers to it or to parts of it.
The most complicated part is to figure out what kind of event messages to send from the Model (and it's parts) to the registered View(s) and their parts. (the idea of a queue I read in one of the responses seems very good, must try it sometimes)
Controllers can be unique for each user input source (keyboard, mouse, joystick, drawing tablet...) but when using GUI libraries, a dedicated Controller for each View is probably more natural to implement.
In this way it is possible to implement very different views on the same Model.
Let's take a 3D drawing program. Objects as 'Car' 'WheelFL' 'WheelFR' etc. would be part of the Model. What kind of views can be implemented ?
GUI for drawing 2D x-y
GUI for drawing 2D x-z
GUI for drawing 2D z-y
GUI for drawing 3D x-y-z
reporting view, web based
reporting view pdf
Each 2D view can represent a wireframe/rendered image constructed from 'WheelFL' in the same application.
The pdf tool can be a batch process that opens all drawings and iterates over all of it's objects and creates a pdf with names, coordinates, etc. User input (controller) can be nothing more than a command line argument, or a configuration file, in the last case.
BTW, I have learned most of this the hard way, but I'm more than ever convinced of the necessity of MVC on different levels (app -> widgets) to make maintainable large (GUI) applications.
Slashdot Mirror
I think the MVC concept is mostly interpreted as a simple design pattern. But it is a much older (measured in IT eons) concept than a design pattern.
MVC is about separating data and behavior (Model) representations (Views) and user input (Controllers).
It can be applied to command prompt operated programs, batch processed tasks, web apps and GUI's. IMO, the narrow interpretation stems from the use of Observer-Observable-Event implementations of GUI widget libraries (Smalltalk, Java Swing/AWT, MFC, VB,...)
But MVC can be applied as an architectural pattern to. Implement and identify objects that are conceptual, logical parts of the application. That embody state and behavior. They have to make up the top level 'model'. Every view that is implemented must use the same basic Model, and register different listeners/observers to it or to parts of it.
The most complicated part is to figure out what kind of event messages to send from the Model (and it's parts) to the registered View(s) and their parts. (the idea of a queue I read in one of the responses seems very good, must try it sometimes)
Controllers can be unique for each user input source (keyboard, mouse, joystick, drawing tablet...) but when using GUI libraries, a dedicated Controller for each View is probably more natural to implement.
In this way it is possible to implement very different views on the same Model. Let's take a 3D drawing program. Objects as 'Car' 'WheelFL' 'WheelFR' etc. would be part of the Model. What kind of views can be implemented ?
- GUI for drawing 2D x-y
- GUI for drawing 2D x-z
- GUI for drawing 2D z-y
- GUI for drawing 3D x-y-z
- reporting view, web based
- reporting view pdf
Each 2D view can represent a wireframe/rendered image constructed from 'WheelFL' in the same application. The pdf tool can be a batch process that opens all drawings and iterates over all of it's objects and creates a pdf with names, coordinates, etc. User input (controller) can be nothing more than a command line argument, or a configuration file, in the last case.BTW, I have learned most of this the hard way, but I'm more than ever convinced of the necessity of MVC on different levels (app -> widgets) to make maintainable large (GUI) applications.