Initial View Data Population Strategy Question

Tsutetamono's Avatar


25 Aug, 2010 03:43 AM

I'd like to set up a project using the standard mediator pattern for view management, but have reached "analysis paralysis" when it comes to deciding the best way to populate my views with model data. Updating views, I understand -- the mediator gets a communication from the framework with a data payload, and passes it to the view.

My question is -- what's a good clean way to get up-to-date model data into a freshly-registered view/mediator pair with minimal model/mediator coupling?

Here are the strategies I've run across so far.

  1. Inject the model object into the mediator using property-injection. On registration, grab the relevant model object data properties and pass them into the view.
    Pros: Simple
    Cons: Really tight mediator/model coupling. Ignores the communication pattern used throughout the rest of the mediator lifecycle.

  2. Pass the necessary model data into the view at view-instantiation (either through the view constructor, or to the view object's properties prior to being added to the stage). Assumes that the view-instantiating command or parent-view has access to all of the relevant model data necessary to make the view accurately reflect the current model state.
    Pros: No mediator/model coupling.
    Cons: May accidentally lead to having to pipe down a lot of model-data particular to a given child view through parent views that could care less. Dependency bloat throughout the display list.

  3. On mediator registration, dispatch a framework communication that requests a data-refresh. The command triggered by this framework communication tells the models relevant to this refresh-request type to dispatch out their "stuff has changed" events. The mediator is listening for the right model-change framework events, and receives the data payloads as usual, and passes to the view.
    Pros: No mediator/model coupling. Mediator only uses one standard set of framework-communication pathways to initialize/update the view.
    Cons: Mediator/command coupling is stronger than usual, since we need to have a command that understands exactly what model classes have to be told to send out their change events. Possible unnecessary work done in unrelated view classes that happen to be listening for the same model-change-communication.

  4. ???

  5. Profit!

So, what do you think? Best of the three? Other strategies I've overlooked?

  1. Support Staff 1 Posted by Shaun Smith on 25 Aug, 2010 09:42 AM

    Shaun Smith's Avatar

    I'd go for option 1. I wouldn't worry too much about mediator/model coupling. The goal is "appropriate coupling", not "zero coupling".

  2. 2 Posted by Tsutetamono on 26 Aug, 2010 09:38 PM

    Tsutetamono's Avatar

    Excellent, thank you for the swift and decisive advice.

  3. Stray closed this discussion on 12 Feb, 2011 10:49 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac