how to best use MVC architecture in flex 2

April 24, 2007 2:54 PM

trying to set up MVC (model view controller) architecture for a Flex 2 project

myself and a colleague are starting a flex 2 project. we are both new to Flex, and not all that experienced in OOP.

Our question is about components: we have the overall application (the main mxml file) and then other components which are their own mxml files. One is the Controller and one is the DataModel.

From a code point of view, it seems we can only go down: ie, if we put both components in the top level app, we can give them id's and talk "down" to them, but the components cant go "up" and reference a function or variable in the main app.

So the question is, a) is there a way to go "up" and b) is it a good programming practice.

I am currently arguing that the Controller should be called in the Application, and the Data Model called inside the Controller, because the Controller needs access to the data. This way the Application can call Controller functions which access the data and return formatted data to the app. Does this make sense and, if not, how else do we architect it? We initially tried putting both components at the top (application) label, but couldn't get them to talk to each other.

hope that makes sense. thanks!

posted by drjimmy11 to computers & internet (2 comments total)

I'm unfamiliar with "components", but your idea about the Model being called from the Controller sounds correct.

One way to think of models in MVC is that they should work with any sort of interface--for example, the same model should be able to be used in a command line application. If a (web designed) data model couldn't be used in a command line application, you're probably doing something wrong.

The Data Models shouldn't need to reference anything "up" in the controller or the main application.
posted by null terminated at 3:04 PM on April 24, 2007

You could be a little more precise in your discussion of "components".

In general, your controller should be managing the model (or data) objects. It should instantiate them, set their properties and manipulate them as necessary, and pass them of to the view (which knows how to display them and nothing more). You are correct in that all action should go through the controller. The objects that the controller should be passing to the view should ideally be data objects, i.e. objects with just getters and setters.

A slightly more sophisticated version is to have your controller instantiate helper objects; these objects reflect business rules or processes. These objects then instantiate model objects, manipulate them, than pass them back to the controller. The idea then is that your main controller is responsible only for flow control, not business logic.
posted by Nahum Tate at 3:43 PM on April 24, 2007