First of all, keep in mind that my demo is terribly simplified — most operations on the view facade involve much more than simply switching a view (things like resetting fields, clearing validations, etc.).

The commands don’t know anything about a particular view — they simply know about facades. So the separation of concerns is still there, plus the commands have easy access to manipulate the views thanks to the singleton logic.

Our top priority was to minimize the scripting logic in the view components. We tried using state variables/listeners on ModelLocator in the previous attempt, and quickly found that to become confusing and very hard to track and maintain. Each view component had tons of logic around the state of these variables. Refactoring code became hairy, as making tweaks to the logic around these variables potentially could change behavior you didn’t want to tweak. By having very specific methods on the view facades (with descriptive names), the view manipulation logic became very neatly contained, simple to maintain, and safer from a refactoring point of view.

Binding is a fantastic and powerful concept for many things, but it can also very easily be misused. We found that tons of bindings and listeners/logic around view manipulations to be a prime example of “bindings gone bad”.

The main issue here is having commands know the specific view …

Why are you doing a view facade ?
To have code behind ?

Wouldn’t a state variable(with a watcher on it) in a model from ModelLocator be enough for you to to show progress/hide progress/display list/select child/etc… and keep all that pesky view code in the view itself?