> So, one flaw in the approach they displayed is the mediator is kicking off two asynchronous processes
hmm, seems like the diagram wasn't very clear on that point. there's only one asynchronous action there: making a network request back to the server for fresh data, which by its nature has to be an async op. everything else is synchronous (including Backbone's event handlers).
> The "Orchestrator" should hire some subordinates and delegate work to them in an effective manner.
this is precisely what's happening: the orchestrator basically does nothing but delegate between subviews and the model layer, ensuring that messages are passed around as appropriate. the text probably didn't make clear enough that this is supposed to happen at any sufficiently complex portion of the UI ("This pattern is repeatable: any sufficiently large or complex area of an app (such as a single route) may hold its own mediator to encapsulate the details of its UI interactions and communicate with the Model layer with a small, well-defined API"). we don't really consider interactions between UI components to be "business logic;" if the 'mediator' started turning into an uber-object with many responsibilities we would probably look at breaking it into services (or putting the right bits back into the model layer), but we try pretty rigorously to avoid premature abstractions...
hmm, seems like the diagram wasn't very clear on that point. there's only one asynchronous action there: making a network request back to the server for fresh data, which by its nature has to be an async op. everything else is synchronous (including Backbone's event handlers).
> The "Orchestrator" should hire some subordinates and delegate work to them in an effective manner.
this is precisely what's happening: the orchestrator basically does nothing but delegate between subviews and the model layer, ensuring that messages are passed around as appropriate. the text probably didn't make clear enough that this is supposed to happen at any sufficiently complex portion of the UI ("This pattern is repeatable: any sufficiently large or complex area of an app (such as a single route) may hold its own mediator to encapsulate the details of its UI interactions and communicate with the Model layer with a small, well-defined API"). we don't really consider interactions between UI components to be "business logic;" if the 'mediator' started turning into an uber-object with many responsibilities we would probably look at breaking it into services (or putting the right bits back into the model layer), but we try pretty rigorously to avoid premature abstractions...