The reason for VM class to explode in size is that it is carrying too much responsibility.
1. Provide binding properties
2. Provide binding commands
3. Provide implementaion for commands and other functions required by the View and its code behind.
For a complicated view, it won't take long for the view model class to reach unmanagable size. To solve this problem we need to delegate some of the functions to other classes. But the View class still requires a binding target. Instead of using a View Model class, I'll call this simplified view model class Abstract View in that it defines the possible properties and operations a concrete view that is bound to it may carry out hence define the view in an abstract manner.
Here is a static view of this new pattern.

By using more than one CommandProviders, you can separate concerns horizontally and by allowing CommandProviders to user other delegates, you can separate concerns vertically. Mediators become facades for various delegated function units each providing service of a subject area.
This is a sequence diagram for starting up.

A typical user edit action sequence.

A typical user command handling.

Close view.

In this pattern, most of the functionality is moved out of the "ViewModel" class therefore it's size will be under control. When the Mediator size is grown out of control, it may optionlly use other delegates to redistribute its functionality.
Nice, I like it, thanks!
ReplyDelete