Author
What is MVC really? Is "model-view-controller" basically the way all ASP.NET programs in Visual Studio are made? Is it the default way WPF applications are arranged?
MVC is just a programming concept, nothing more, nothing less. It is used in several places, reaching from frameworks, libraries to game engines. Most often the MVC concept is used in a modified way, suiting better the project requirements
It's an architectural modal mostly used for web frameworks. Typically like this:
For GUI applications on the desktop (especially WPF and anything XAML-based), MVVM (or MVP) is a more appropriate pattern
I've seen some attempts at applying MVC to games. You'll have to adapt it a bit, but the following would be entirely possible, for example:
- You've got the model which represents your state / your data as objects. For a blog, your model might consist of a repository of post objects which contain text and comment objects.
- A controller responds to requests from the outside. For example, accessing the url http://example.com/article/show/123 might load the ArticleController and call its Show() method with the parameter 123 in modern MVC frameworks. It will then look up the blog post in the model, create an appropriate view and feed it the data it needs (so the view isn't coupled to the model)
- Each view has a well defined set of inputs (to be filled by the controller) and is responsible for presenting these inputs (for example, a blog post and associated comments) to the user (in this case, by generating HTML code).
For GUI applications on the desktop (especially WPF and anything XAML-based), MVVM (or MVP) is a more appropriate pattern
- The model represents the data, either by interfaces with a data store or holding it directly, just like in MVC.
- The viewmodel (or presenter) refines the data to a format on which data binding can be applied. Data binding means that instead of letting the view create a listbox and filling it with all the items it should display, you tell the listbox to display the contents of a collection and describe how items are to be represented visually. The viewmodel also provides commands, for the view to invoke, typically via methods like Accept(), AddItem(), DeleteSelection(), etc.
- The view binds to the data exposed by the viewmodel.
I've seen some attempts at applying MVC to games. You'll have to adapt it a bit, but the following would be entirely possible, for example:
- The game's model contains the state of the world. It does not hold any references to anything graphics-related and could run the game in a console application. If something in the world changes (eg. a new building it added), it triggers an event (eg. using a signal/slot system)
- The game's presenter observes the model and creates/destroys entities in the game's scene graph and updates existing entities for according to what happens in the model. The presenter could be reused in the main game and the editor.
- The game's controller makes use of the presenter to render the world and adds its own stuff on top. If the controller was a map editor, it might add toolbars and object picking / moving overlays. If the controller was the game, it might add command panels, a health display or similar things on top of the rest.
It's an architectural modal mostly used for web frameworks. Typically like this:
You've got the model which represents your state / your data as objects. For a blog, your model might consist of a repository of post objects which contain text and comment objects.
A controller responds to requests from the outside. For example, accessing the url http://example.com/article/show/123 might load the ArticleController and call its Show() method with the parameter 123 in modern MVC frameworks. It will then look up the blog post in the model, create an appropriate view and feed it the data it needs (so the view isn't coupled to the model)
Each view has a well defined set of inputs (to be filled by the controller) and is responsible for presenting these inputs (for example, a blog post and associated comments) to the user (in this case, by generating HTML code).
The view is presenting the model or part of the model. The presentation is controlled by the controller, but the data comes from the model.
edit: Maybe i read that out of context. But i am not sure if such a web system is an implementation of the MVC pattern
edit2: Abstracting the model from the view ist more related to the model-view-presenter pattern i guess.
For the application in games, i guess certain component based entity systems are an implementation of the MVC pattern. That is, there exists a collection of entities, which are more or less only dynamic containers containing data, representing the model. Then you have systems operating on the model, like physics, AI, user controls, which are the controllers. Then there are other systems which render the entities on the screen, i.e., the view part.
Everyone has their own pet definition of MVC. It has been stretched and tweaked over time to fit different programming scenarios and there are now countless variants (it seems).
Nowadays, it's probably best to ask "what does the framework I'm using mean by MVC?", rather than "what is MVC?".
FWIW, the original definition comes from Smalltalk.
Nowadays, it's probably best to ask "what does the framework I'm using mean by MVC?", rather than "what is MVC?".
FWIW, the original definition comes from Smalltalk.
The view is presenting the model or part of the model. The presentation is controlled by the controller, but the data comes from the model.
Isn't that pretty much what I said? The only difference I spot is that for you the view directly connects to the model. In the case of web frameworks employing MVC like RoR, Symfony or ASP.NET (which the paragraph you quoted was about) the controller usually collects the data to be presented in the view and puts it into a property container that gets passed to the page templating engine (eg. Smarty, NVelocity).
The view does not usually have access to the model in such web frameworks. That adds some flexibility: views don't always show the model (think error pages), views only get the inputs from one source (the controller is always in the loop, even if the view can, for example, look up the users in the model itself, it doesn't know which user is logged in and making the request - that information is in the controller) and it adds some symmetry since the controller is the one receiving the view's outputs already.
But as edd said, lots of things are now called MVC and that's only how the majority of web frameworks use it. It's less used in desktop applications (see my explanation of MVP / MVVM) and I haven't found a way to apply it to real-time applications without butchering it a bit (see my third explanation, which I didn't just dream up but actually used in a game ;))
[quote name='Inferiarum' timestamp='1342533682' post='4960007']The view is presenting the model or part of the model. The presentation is controlled by the controller, but the data comes from the model.
Isn't that pretty much what I said? The only difference I spot is that for you the view directly connects to the model. In the case of web frameworks employing MVC like RoR, Symfony or ASP.NET (which the paragraph you quoted was about) the controller usually collects the data to be presented in the view and puts it into a property container that gets passed to the page templating engine (eg. Smarty, NVelocity).
The view does not usually have access to the model in such web frameworks. That adds some flexibility: views don't always show the model (think error pages), views only get the inputs from one source (the controller is always in the loop, even if the view can, for example, look up the users in the model itself, it doesn't know which user is logged in and making the request - that information is in the controller) and it adds some symmetry since the controller is the one receiving the view's outputs already.
But as edd said, lots of things are now called MVC and that's only how the majority of web frameworks use it. It's less used in desktop applications (see my explanation of MVP / MVVM) and I haven't found a way to apply it to real-time applications without butchering it a bit (see my third explanation, which I didn't just dream up but actually used in a game ;))
[/quote]
I guess there is some room for interpretation. But the way you describe the controller I would actually describe the view. It works on the model data and turns it into something presentable, which in this case is handed on to something else, i.e., the view has multiple layers. In my interpretation, the controller would be an entity changing the model data an/or sending the commands to the view which control what actually should be presented. In your example I would say the controller is the object processing the url and calling the 'ArticleController' (i.e. the view)
In your example I would say the controller is the object processing the url and calling the 'ArticleController' (i.e. the view)
That job is usually done by a Router, RouteHandler or similar class in such frameworks (actual code: ASP.NET MVC, Ruby on Rails, Symfony), which then typically uses a ControllerFactory to build the ArticleController or PostController or similar.
The whole thing would have been easier if they picked less abstract terms.
DLP for example. Data, Logic and presentation. Much easier to grok.
In a nutshell, keep logic out of your presentation layer and your data layer and you are doing MVC in some manner.
DLP for example. Data, Logic and presentation. Much easier to grok.
In a nutshell, keep logic out of your presentation layer and your data layer and you are doing MVC in some manner.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
