MVC Question

[Groady]

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]

Originally Posted by Groady

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]

I use PureMVC 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]

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

[yell0wdart]

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]

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]

/agree. A dumb model is a good model.

[Groady]

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]

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]

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?