PDA

View Full Version : MVC Question


Groady
11-22-2008, 12:50 AM
I'm just looking for some advice on implementing an MCV design pattern for a game I'm developing in AS3.

Specifically I'm a little stuck on where I should be instantiating display objects from. I understand the model performs all the logic of a program and is unaware of any views reading from it. My problem is I need the model to be able to access certain display object so it can perform localToGlobal operations on them and their positions accordingly.

I can think of 2 ways to solve this but I'm not sure which way is better (or neither).

The first way is to pass a reference of the display object to the model (via the controller of course).
The second way is to instanctiate all view objects through the model with Factory methods, that way the model retains references to everything it creates.

I guess I'm just wondering if anyone has any suggestions or if their is any 'official' way to do it.

yell0wdart
11-22-2008, 03:12 AM
I'm just looking for some advice on implementing an MCV design pattern for a game I'm developing in AS3.

Specifically I'm a little stuck on where I should be instantiating display objects from. I understand the model performs all the logic of a program and is unaware of any views reading from it. My problem is I need the model to be able to access certain display object so it can perform localToGlobal operations on them and their positions accordingly.

I can think of 2 ways to solve this but I'm not sure which way is better (or neither).

The first way is to pass a reference of the display object to the model (via the controller of course).
The second way is to instanctiate all view objects through the model with Factory methods, that way the model retains references to everything it creates.

I guess I'm just wondering if anyone has any suggestions or if their is any 'official' way to do it.

I think the latter option would be your most elegant solution. Implement a factory or builder pattern to manage instantiation. Though, I'd probably put that logic in the business layer, rather than the data access layer.

rawmantick
11-22-2008, 04:40 AM
I use PureMVC (http://www.puremvc.org/) framework in almost every project.

If you use this framework, your first thing to do will be notyfying observers of application facade. Spend some time for learing this, and you will be greatfull to developer who made it:)

Groady
11-22-2008, 03:15 PM
I'm aware of PureMVC. However I feel the best way to learn things is to create them myself. I'll probably learn the PureMVC framework for my next project.

My MVC is created as described in the O'Reilly book Actionscript 3.0 Design Patterns.

@yell0wdart, I was leaning towards that way too unless somthing better presents itself. I'm not sure what you mean by Business layer however :confused:

yell0wdart
11-22-2008, 04:56 PM
Business layer roughly means controller. In most multi-tiered architectures you generally have 3 or more layers which are commonly called the Data Access Layer or DAL (ie: Model), the Business Logic Layer or BLL (ie: Controller) and your Uuser Interface or UI (ie: view).

It's a pretty simplified explanation, as some architectures can have more than 3 layers, but you get the idea. ;)

creynders
11-23-2008, 11:53 AM
yep you can make the controller responsible for creating the views, since a controller is always tightly coupled to a view anyway. NEVER put it in the model, though. You'll create a monolithic model which is too aware of the entire application and therefore you'll be defeating the whole purpose of MVC.
I too am a fan of pureMVC, since it's so... pure. It really is just an enhanced MVC framework.

yell0wdart
11-23-2008, 03:07 PM
/agree. A dumb model is a good model. :)

Groady
11-23-2008, 03:36 PM
Would I be right to assume that any ENTER_FRAME events should exist outside the model in the view?

So in the case of say a Flash game, a player or enemy object would send it's position to the model which in turn update's itself and dispatch's an update to it's observers?

Currently I have it the other way around where my model fires it's own ENTER_FRAME event requiring the model to be a DisplayObject to inherit the enter frame functionality.

Thanks for the help so far :)

acolyte
11-24-2008, 11:00 AM
mhh not exactly shure what you mean ,

i would say yeah the onEnterFrame is only necessary for updating the View but i wont use onEnterFrame for observer use the as3 equivalent for objectpropertywatch() aka observer pattern you will have much less on overhead then when tracking with onEnterFrame

Groady
11-24-2008, 08:49 PM
I think I may be taking the whole MVC thing too literally.

I've lost track of the fact that the view represents the user input and output and doesn't necessarily mean that a DisplayObject can not be referenced in both the view and the model.

I think the best way for me to approach it is to have factory methods accessible through the model itself which instantiate any game related assets such as the player, enemies, powerups etc. This way the model will be able to keep track of the game object's data such as position, rotation etc. but also be able to perform methods specific to DisplayObjects such as hitTest and localToGlobal.

Even though the model will have direct access to a DisplayObject's properties it won't change them directly. Rather it will read them, manipulate them and store the changed value after which all subscribed observers will be notified of the change and read the new value from the model. This should retain loose coupling between the view and the model.

What do you think?

creynders
11-25-2008, 09:47 AM
That doesn't sound right. IMO, a model shouldn't access a view's properties directly, since it will need a reference to the view and that tightens the coupling.
Also, the responsibility of collision detection isn't that of the model's but of the controller's. They can in turn notify the model that a colission has occurred.
And, as I said instantiation is also a responsibility of the controller, or if you wish of the main Application class, not of the model.
The model stores data and notifies the framework of changes to that data; that's it. Of course what falls under the definition of 'data' is debatable.
The data that is stored in the model should be restricted to information that is necessarily shared. This is something I forgot a lot when I started learning MVC.
If there's no need to share the data then it should be stored in the view and/or the controller, not the model.
Also, you don't have to be afraid of using delegates and helper classes.
For instance, if you need a "tick", a signal that a certain amount of time has passed, you don't need to put that logic inside the model, you can just as easily create a helper class that notifies the model of the tick. It has the added benefit that if at a certain point you want to change the type of tick (for instance from frame-based to time-based) you don't have to start meddling with your model, but just change the inner workings of the helper class.
You need to spread responsibilities. In general try to describe everything what a class does in 5 to 10 words, if you can't, chances are you've given it too much responsibility and need to create additional classes that take responsibilities over.

Hope this helps.

And, always try to favor composition over inheritance. You decided to have your model inherit from DisplayObject since you needed the enterFrame event, but that means you're stacking your model with a bunch of unnecessary overhead. You could've just as easily let the model create a display object and listen to it's enterframe event. Or even easier just listen to the stage's enterframe event. (But as I said, I think it's best to hand out that responsibility to a separate class)

Groady
11-25-2008, 03:08 PM
Thanks for your input creynders.

You raise some good points. I think I'll have more of a play with it and make sure the model only stores values and not references to any views. I had considered using a helper class for a tick so I think I will do that.

In regards to handling collisions, I guess it makes sense for the controller to handle it so that it can decide whether the model needs to be informed of the collision or to simply update the view without effecting the model.

I think the moral is that a controler acts as a kind of buffer to test if certain conditions need to change data application-wide or only effect a view's cosmetics.

NickZA
12-05-2008, 08:21 AM
In regards to handling collisions, I guess it makes sense for the controller to handle it so that it can decide whether the model needs to be informed of the collision or to simply update the view without effecting the model.

Worth looking at this "variation" of MVC known as PAC:
http://en.wikipedia.org/wiki/Presentation-abstraction-control

Also, the responsibility of collision detection isn't that of the model's but of the controller's. They can in turn notify the model that a colission has occurred.
And, as I said instantiation is also a responsibility of the controller, or if you wish of the main Application class, not of the model.
The model stores data and notifies the framework of changes to that data; that's it. Of course what falls under the definition of 'data' is debatable.
The data that is stored in the model should be restricted to information that is necessarily shared. This is something I forgot a lot when I started learning MVC.
If there's no need to share the data then it should be stored in the view and/or the controller, not the model.

Excellent point, this is something I am discovering at the moment as I build separate renderers for my MVC-based game which both rely on the data model of the tile-map which represents the game's play area -- one very quickly sees what is truly crucial to the concept of the tiles as object, and (separately) to their display/rendering in both 2D and pseudo-3D modes. The allows for a "distillation", if you will, of data members and methods which use those members, according to the needs of the various classes: model vs. 1st view vs. 2nd view.

Also, you don't have to be afraid of using delegates and helper classes.
For instance, if you need a "tick", a signal that a certain amount of time has passed, you don't need to put that logic inside the model, you can just as easily create a helper class that notifies the model of the tick. It has the added benefit that if at a certain point you want to change the type of tick (for instance from frame-based to time-based) you don't have to start meddling with your model, but just change the inner workings of the helper class.
You need to spread responsibilities. In general try to describe everything what a class does in 5 to 10 words, if you can't, chances are you've given it too much responsibility and need to create additional classes that take responsibilities over.


On this note, it's worth checking out the Chain of Responsibility Pattern (wikipeida, www.as3dp.com).