It takes a while to get going after the holidays, but once I had dusted the mince pie crumbs from the thinking cap it was business time.

As you may be aware from previous posts, I'm a regular user of the various flavours of the MVC pattern (MVC, MVP, Supervising Presenter etc.  I'll just refer to it as MVC from now on, even though the exact pattern I'm using may not be that).  The software might take a little longer to construct, but this will pay back in maintainability, testability, legibility and other -bilities.  

The task for today was to apply a user-defined 'mask' over a datasource that was bound to a grid.  In this specific case, we apply the mask to the grid instead of the datasource, but the principles would be the same if our requirements were to modify the datasource in some way.

We have 3 MVC-triads involved, and the associations between which (and classes) are illustrated below:

The 'Super' triad, shown in green, is where it will begin.  The Window will receive the click event to show the Top N dialog, which will notify the WindowController.  The WindowController will then create the concrete TopN View (the dialog), passing this into the TopNController.

When the user clicks the 'Apply' button on the Top N dialog, this will communicate the specified values to the TopNController, which will then modify the PivotViewDef.  Note: The PivotViewDef is stored by the Document, and bound to the GridView by the GridController on instantiation.  We use a simple Observer pattern for this, which means that whenever PivotViewDef is modified, we broadcast this change to any interested parties, which can then take action.

Therefore when the PivotViewDef is modified, it will automatically refresh the GridView.

This is a clean and elegant design, as it removes any logic from the forms.  The inter-dependencies between the various components are also limited, which reduces the complexity.  And because the TopNController only communicates to the view via an interface, it is inherently unit-testable.