Jump to content
  • Advertisement
Sign in to follow this  
athono

MVC

This topic is 2159 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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).


    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.
        Edited by Cygon

Share this post


Link to post
Share on other sites

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. Edited by Inferiarum

Share this post


Link to post
Share on other sites
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. Edited by Inferiarum

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ;)) Edited by Cygon

Share this post


Link to post
Share on other sites

[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)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!