Passive view-Martin's "Gui ubuntures" series (4)

ArticleDirectory

• Passive View

ZZ from www.martinfowler.com

To be translated...

Passive View

A screen and components with all application specific behavior extracted into a controller so that the widgets have their state controlled entirely by controller.

A perenrix problem with building rich client systems is the complication of testing them. Most rich client frameworks were not built with automated testing in mind. controlling these frameworks programaticly is often very difficult.

APassive ViewHandles this by grouping the behavior of the UI components to the absolute minimum by using a controller that not just handles responses to user events, but also does all the updating of the view. this allows testing to be focused on the Controller with little risk of problems in the view.

How it works

This pattern is yet another variation on Model-View-controller and Model-View-presenter. as with these the UI is split between a view that handles display and a controller that responds to user gestures. the significant changePassive ViewIs that the view is made completely passive and is no longer responsible for updating itself from the model. as a result all of the view logic is in the controller. as a result, there is no dependencies in either direction between the view and the model.

Figure 1: unlike most MVC-style configurations,Passive ViewResults In no dependencies between view and model.

Looking at our regular assessment window example, again we see a view/controller split, but this time the controller does all the work in figuring out how the view shoshould display the model. the text Field widget changes es the user gesture but immediately hands off to the Controller, in the classic MVP movement. the Controller then updates the model, and then handles the reloading of the view from the model. this load actions involves pulling all the data needed from the model, and using it to update the widgets. this example shows a coarse-grained synchronization, where any change results in a complete reload.

Figure 2: when the actual text is edited, all the UI response is handled by the Controller.

Figure 3: classes for the assessment example.

The primary driverPassive ViewIs testing, As a result it's often valuable to use of test double for the view so that the controller can be tested without needing any interaction with the UI framework. this needs a intermediate gateway to be setup as in Figure 4. this is the same technique that you wocould use for supervising controller. as with supervising controller I 've shown a stub here, but this is also a good opportunity to use a mock.

Figure 4: setting up the view as a gateway so that it's easy to substitute the window with a test double

When to use it

The driving reason to usePassive ViewIs to enhance testability. with the view when CED to a dumb slave of the controller, you run little risk by not testing the view. the controller can run and be tested outside of the UI environment-indeed if you use a test double for the view you don't need to even have the UI classes available to you.

Passive ViewIsn't the only way make the view sufficiently humble to help in testing. Presentation Model and supervising controller are both reasonable alternatives. The strength thatPassive ViewHas over these two is that both of the alternatives require the view to do some of the synchronization work, which results in more untestable behaviorPassive View. Whether this difference is significant or not is a judgment call.

Another advantage thatPassive ViewIs a very explicit mechanic. there's very little reliance on Observer mechanic ms or declarative mappings. this makes it much easier to read the code to see what is happening-fig if you're Trying To debug when things go wrong.

Significant revisions

18 Jul 07:First publication in development area of website.