Thanks for the explanation Cliff.

I've got a few questions off this, though.

1. In a fully decoupled environment, everything should request objects through the facade, Mediators -> Facade -> Proxies/Mediators.  Commands -> Facade -> Proxies/Mediators.  For performance reasons (games), it should be ok to at least cache the result of the facade get, right?  Something like

:

var cachedStageMediator:StageMediator in another Mediator?

2. Again, for performance, there are always going to be Singleton Mediators/Proxies.  For instance, the StageMediator in my system is responsible for emitting resize messages, and also contains our window/viewport system.  It's general and won't be changed, certainly within the same project lifecycle, so it could make sense to expose a public static singleton accessor instance().

3. Likewise, singleton VOs seem like they could be ok with static accessors/variables, especially given they aren't necessarily connected to an MVC Proxy.

4. If I go the 'pure' path, and design VOs first, followed by the View Components that display them, before building the plumbing into Mediators/Proxies, accessing everything via the facade, what objects do you typically build VOs for?  i.e. Do you just build VOs for marshalling data around between the various MVC classes, or do AS3 programmers tend to use them in place of traditional data structures defined as classes?

I guess what I'm really trying to work out, is do you tend to use the MVC as scaffolding to link up the views with their data, with the commands acting as a bit of glue, whilst leaving the rest of the app/game to manage their systems internally.  i.e. The whole app/game could be in a single Mediator GameMediator, with custom drawing etc, with traditional data structures kept as an internal detail, with the rest of the HUD, or title screen, or high scores etc as their own Mediators.

Cheers,
Shane

Hi,

I've only used PureMVC for a couple of days, but I really like how it's constructed.  I'm mainly from a C++ background, so there are a couple of questions I have around Proxy objects and Value Objects (VOs) that I hope aren't painfully obvious to AS3 people.

Firstly, I'm not sure I fully understand the purpose of VOs.  I thought the whole idea behind Proxies was to hide the actual data representation, exposing necessary data via getter/setters.  The way I'm seeing them used is sort of an exposed key/value pair hanging off the proxy.  Are they meant to be sort of read-only objects, with the write interface being the proxy?  Or are they read/write?  If they're read AND write, this breaks encapsulation, so I'm confused.  Or are these types of VOs meant to be very simple, with pretty much non-existent Proxy objects?

Secondly, in researching PureMVC architecture, I'm seeing a lot of people have a VO full of static variables for singleton-type classes.  For example, it seems common to have an ApplicationVO where programmers access its data from anywhere using ApplicationVO.someThing.  I've even seen ApplicationVO classes with functions, that return data.  For example, I've seen one class that looks like this:

:

class ApplicationVO
{
  public static var FILESYSTEM_ROOT="some_directory/";
  public static var BASE_IMAGE_FILENAME="img_";

  public static function getPath(filename:String):String {
    return FILESYSTEM_ROOT+BASE_IMAGE_FILENAME+filename;
  }
}

I'm not sure if I'm missing the point, but shouldn't all of this be in the Proxy?

I'm seeing similar patterns in Mediators; i.e. static functions in mediators, or singleton mediators (BlahMediator.getInstance()).  Isn't this again killing loose coupling?

If the answer to all of this is simple, it's convenient, or it's because of performance, then I get it.  I'm from a console video game programming background so I understand tighter coupling for the sake of performance.  Still, why have both static Proxies AND VOs?  Why not just have a static Proxy which exposes the VO, like so:

:

class MyVO {
  public var blah:int = 0;
}

class MyProxy extends Proxy {
  private var _myVO:MyVO;
  private static var _instance:MyProxy;

  public function MyProxy() {
    _myVO = new MyVO;
    _instance = this;
  }
  public static function get instance():MyProxy {
    return _instance;
  }
  // at most expose the VO via a static in the proxy
  public static function get vo():MyVO
  {
    return _instance._myVO;
  }
}

This is how I've decided to implement singleton-type proxy objects.  Is this the right way to go, or am I missing something?

I've got more questions, but this is a good start

Cheers,
Shane