I was struggling with the same issues and decided to adopt a
simple routine. I did not create this, it was suggested by a fellow
I build each view or component of an app with the following
- MyView (Sprite or other display object) - MyViewModel (Actor) -
MyViewMediator (Mediator) - MyViewEvent (Event)
The view exposes the necessary functions to be updated by the
mediator as needed. If the data is complex, I pass Value Objects.
It has no awareness of either the Model or the Mediator.
The Mediator usually has 2 injections the View and the Model.
Its job it to update the view with the data from the model. Or
update the model with the data from the view and tell the app it
has been updated. It registers listeners for the various events it
handles and dispatches events as needed. All these are defined in
the MyViewEvent class. The mediator has no concept of the rest of
The Model is updated by the Mediator, following user input in
the view, or via Commands by other actors in the app.
Events do not carry any data. Usually an "update" event would
tell the Mediator to update the View with Model data. And a
"change" event is dispatched by the Mediator when the View has
The flow is simple App Event > Execute Command > Update
Model >Dispatch Event > Mediator Event Handler > Update
View. Or View Signal > Mediator updates Model > Mediator
DIspatches Event > App Executes Command > ...
This tends to be boilerplate code heavy, since I creates 4
classes, minimally, per view. But I find this regimented mode to be
quite flexible. A view components ends up being 100% self contained
and can be poped into another app with little or no re-write.
It also clearly segment the roles and responsibilities of the
various actors. I find that managing the flow of data can be
tricky, especially when many actors start firing events and trigger
actions, keeping track of who does what can be hell.
My last project ended up having over 4000 lines of code written
in 2 weeks with quite a few moving parts (2D overlays, Away3D
content and dynamic data) and without this structure I wouldn't be
able to manage. Might not work for everything, but so far it served
me well :)
As Joel likes to say, "it's about 'appropriate coupling' not 'no coupling'"
I've used models injected into views. Even when I'm doing that I prefer to
treat the models as "read only" and use other mechanisms to set values on
the models. Once I even created a read-only interface for the models that I
used for mediator injection, just to enforce it. That did end up being a
bit more complicated from the mapping side because you can't just use
"injector.mapSingletonOf()" (since you really need two mappings per model
-- one read-only and one writeable).
However, I have also seen projects that end up with a lot of tangled code
that's hard to follow, that would not have been possible if we weren't
injecting models into mediators. For me personally, I've decided that the
benefit of having fewer commands and events isn't worth the risk of
complicated mediators. But that's just what works best for me.