If you want an easy way to learn MVC, pick up this book and go through
the tutorial:
Agile Web Development with Rails
The Ruby on Rails MVC structure is easy to implement and understand and
it will set you on your way in MVC. They've got great naming
conventions, too.
You should use the MVC design pattern with companion patterns like
Decorator and/or Observer. Also, Flash blurs the lines between
Controller and View and sometimes it's not worth over-architecting and
over-abstracting things. At the end of the day, you need to get the
project done while keeping your codebase managable. Most of the time,
you're not going to be swapping out too many pieces of your MVC, and so
MVC becomes a tool for organizing your code into logical pieces. An
example of swapping out would be if you changed the model from using XML
to Remoting. Or you change the view from using combo boxes to some
custom UI implementation. The events/data they pass should stay
(basically) the same even if their internal implementation changes
completely.
One strength of MVC is to decouple the model from the view from the
controller such that you can replace any single one of them at any time
and not have to touch the code in the other two. Your code example uses
direct references to the view from the model, which is counter to this
purpose, and event dispatchers and/or accessor methods will fix that.
The model just says "I've updated" to whoever is listening and the
view(s) that are listening receive that event and takes appropriate
action. The model doesn't know or care what the view or controller is
or anything about how they work. It only cares about managing the data
and dispatching events when that data is created, modified, updated,
deleted, etc..
Here is a simple class that Decorates Movieclips with event dispatchers.
I extend my Controller and View classes with this class. My Model class
is the same but it doesn't extend MovieClip since Models are just data.
import mx.events.EventDispatcher;
class com.stevensacks.mvc.ViewController extends MovieClip
{
public var addEventListener:Function;
public var removeEventListener:Function;
private var dispatchEvent:Function;
function ViewController ()
{
EventDispatcher.initialize(this);
}
}
In the model class, you dispatch events. Views will add themselves as
listeners to those events and take appropriate action. In MVC, the
Controller renders the View, the View listens to the Model and talks to
the Controller, which updates the Model, which broadcasts an event that
it has updates for any views that are listening. Here is a trivial
example, and I am using direct access to certain methods for sake of
brevity, but you could have event listeners and delegated events between
the M V and C to decouple them completely.
/////////////////////
import com.stevensacks.mvc.Model;
class com.clientname.MyModel extends Model
{
private var data:Object;
function MyModel()
{
super();
}
private function doUpdate():Void
{
dispatchEvent({type:"update", data:data});
}
public function set someProperty(str:String):Void
{
data.someProperty = str;
doUpdate();
}
}
////////////////
import com.clientname.MyModel;
import com.clientname.MyView;
import com.stevensacks.mvc.ViewController;
class com.clientname.MyController extends ViewController
{
private var model:MyModel;
private var view:MyView;
function MyController()
{
super();
model = new MyModel();
model.addEventListener("update", view);
view.controller = this;
}
function changeProperty(str:String):Void
{
// do something with the data
// or just pass it through to the model
model.someProperty = str;
}
}
/////////////////
import class com.clientname.MyController;
import com.stevensacks.mvc.ViewController;
class com.clientname.MyView extends ViewController
{
public var controller:MyController;
private var TXT_Field:TextField;
function MyView()
{
super();
}
function update(evt:Object):Void
{
// receive the data when the model updates
draw(evt.data);
}
private function draw(data:Object):Void
{
// draw the view with the data
}
function makeSomeChange():Void
{
// something is changed
controller.changeProperty(TXT_Field.text);
}
}
//////////
It's important to note that with the Composition pattern, you might not
have every view listen to the model, but instead have a parent object
(composite) listen and it will manage passing the update down to its
children (composites or components). You can simulate this by having a
controller with many related views listen to the update and then pass
the update as needed to its views, but there are better ways to do that,
including the Strategy and Chain of Responsibility patterns which work
well with Composition.
Check out this book for more inspiration:
http://tinyurl.com/yav644
HTH,
Steen
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
