Using MVC with a retained mode renderer
- by David Gouveia
I am using a retained mode renderer similar to the display lists in Flash. In other words, I have a scene graph data structure called the Stage to which I add the graphical primitives I would like to see rendered, such as images, animations, text. For simplicity I'll refer to them as Sprites.
Now I'm implementing an architecture which is becoming very similar to MVC, but I feel that that instead of having to create View classes, that the sprites already behave pretty much like Views (except for not being explicitly connected to the Model). And since the Model is only changed through the Controller, I could simply update the view together with the Model in the controller, as in the example below:
Example 1
class Controller
{
Model model;
Sprite view;
void TeleportTo(Vector2 position) { model.Position = view.Position = position; }
}
The alternative, I think, would be to create View classes that wrap the sprites, make the model observable, and make the view react to changes on the model. This seems like a lot of extra work and boilerplate code, and I'm not seeing the benefits if I'm just going to have one view per controller.
Example 2
class Controller
{
Model model;
View view;
void TeleportTo(Vector2 position) { model.Position = position; }
}
class View
{
Model model;
Sprite sprite;
View() { model.PropertyChanged += UpdateView; }
void UpdateView() { sprite.Position = model.Position; }
}
So, how is MVC or more specifically, the View, usually implemented when using a retained-mode renderer? And is there any reason why I shouldn't stick with example 1?
