Swiz example application with Passive View pattern
Passive View is another presentation pattern that can be used to increase the testability of graphical applications. It does this primarily by extracting all logic and state from your views, making it pointless to test the view itself. In fact, in the article linked above, Martin Fowler says the following:
With the view reduced to a dumb slave of the controller, you run little risk by not testing the view.
You instead test the component to which the logic and state have been extracted. This component can be referred to by names such as mediator, presenter or controller but the name itself is irrelevant. What is important is that it is not a view component (meaning it does not exist on the display list, in Flash/Flex specific terms), which are inherently hard to unit test. In the example application I have created I refer to these components as mediators.
Example Application
For this post I have simply converted the Swiz example application I created using the Presentation Model pattern. The conversion took maybe 30 minutes, which includes looking up some of the specifics of the pattern, because I had not actually implemented it before.
Motivations
One of Swiz’s biggest strengths is the flexibility it affords you when using it. Rather than enforcing (or even suggesting) a particular architecture, it provides tools and utilities that help you to create well architected applications. I think showing the same application built with different (albeit similar) presentation patterns demonstrates this point quite well. I will also admit that I was influenced by the RobotLegs Best Practices document in selecting Passive View as the pattern to demonstrate since they demonstrate/promote the pattern there. Hell, I will even admit there was a bit of “anything you can do, we can do better” sentiment on my part. 
That is not meant to take anything away from the RobotLegs team as they are certainly a smart bunch of guys, but I wouldn’t have joined the Swiz team if I didn’t think it was the best thing out there.
Thoughts on Passive View
I sort of like that your views become plain MXML with no logic, state or external references whatsoever when using the Passive View pattern. What I don’t like is what your mediator/presenter/controller becomes in order to purge your view of those things. I feel like you end up with a frankenstein class that is part (presentation) model, part controller and part code behind.
It is not truly code behind since it uses composition rather than inheritance, but it feels the same. You are reaching into the view to add listeners to its child components, setting properties directly on its child components, etc. Handling events from those child components is like a controller, but you also end up storing some state for the view as well. You could obviously break that out into a separate model class but for most views that is going to be massive overkill. I suppose that presentation models are or can be somewhat of a controller and model combination as well too though. I think adding all the knowledge of the view and its internals is what creeps me out most.
I also feel like Passive View fights against the platform a bit. Since the view has no references to anything, binding is not an option. The view can only be updated by user interaction or manually from the mediator, and even for the extremely simple example I created this felt very tedious. I also wonder if testing the mediator could not potentially be complicated by needing an instance of the view it mediates for operation. Flex Unit 4 likely overcomes much of what would have been painful in the past in this area, but I feel like removing view components from the testing process completely is ideal.
In summary, I think Passive View is a decent pattern, but I won’t be abandoning Presentation Model to use it. In my opinion the drawbacks outweigh the benefits, but the same may not hold true for your particular needs and/or preferences.
Further reading
Be sure to read the Martin Fowler piece linked at the beginning of this post (and anything else by Fowler you have time for), and for another example of the Passive View pattern in Flex check out Paul Williams’ post on the topic.
Enjoy!
You can leave a response, or trackback from your own site.
Good write-up, and nice to see a Swiz example with Passive View — it’s my personal choice for presentation. I absolutely despise having to write AS3 in MXML script blocks (partly due to the way the IDE flubs it sometimes, but also because it’s mixing declarative with imperative), so for me the Passive View is the best way to achieve that separation.
Passive View is also nice when the actual UI is being developed by someone else. They build it dumb then I can manipulate it. Very useful, for example, when an artist builds something purely in Flash. They don’t even have to worry about it having a specific “interface” that I program to — I’ll adjust my code.
To make things easier on ourselves, though, I usually consolidate some state in my passive view and take advantage of binding. From your example, I’d expose a “employee” property from my passive view and let the view map the sub fields. No logic, just a higher-level type, which I think still qualifies as a passive view. Of course, if you slide to far along this scale you start to have a View with a Presentation Model built into it, which isn’t terrible.
I actually think Passive View is great for Flash because we have different routes for building views (MXML or Flash Authoring, etc.). Yes, that means the mediator has to have knowledge of how the view works, but I find that’s really always the case: I’ve never been in a practical situation where I wanted to use my mediator code with a different view without the mediator logic changing anyway.
Thanks Troy, you make some good points. I especially appreciate you pointing out that there is room for interpolation and refinement of these two approaches. They do not exist as stark, unrelated schools of thought, but are more like variations on a common goal and there are definitely shades of gray between them that might be appropriate for a particular scenario.
Hi Ben,
Thanks for putting these examples together for comparison between PM and PV. The code is easy to follow and the comments help me understand how Swiz works.
With Passive View, I personally wouldn’t reach into the view’s datagrid and buttons. I would stick to one dot and not violate the Law of Demeter. For example, I would move your Mediator’s selectedEmployee() setter into the view. This would help you avoid the creepiness of digging around in the view’s guts.
I like how super-clean the view code is. Like Troy, I have views created in Flash, so Passive View helps with designer/developer workflow.
Hey Robert,
How would you wire up the buttons’ click handlers and other view handlers then?
I agree that selectedEmployee could probably be moved into the view as you and Troy both suggest, but the mediator would still have to access the text properties of the inputs in order to update the model in response to a save action. In my opinion, if the mediator has to reach in in one instance, why not just let it do it in all instances and keep the view completely dumb?
I also agree Passive View is a good candidate if there is a lot of round-tripping between designer and developer, but would hope I could figure out something closer to Presentation Model if that scenario arose.
Thanks for reading and commenting,
Ben
I would probably have the view put an Employee instance into an EmployeeEvent event, maybe EmployeeEvent.SAVE event, and dispatch it.
Very interesting article!
I’ve (kind of) recently discovered Swiz and must say I’m impressed with what I’ve seen. I’m used to Java development with Spring, so Swiz is obviously looking good to me. Examples like these make it easier to figure out how to apply it to your own applications. Keep it up!
I think that is a perfectly valid approach, but I don’t think it qualifies as Passive View. I think PV takes things a bit too far, and would actually prefer something like what you describe.
You may be right. I am seeing now that there is a spectrum between Passive View and Presentation Model.
You’re the man Ben. I think the most valuable thing here is that Swiz does not force the developer into a specific architectural implementation. This is proven by these examples, where you are taking different enterprise architectures as identified by Martin Fowler (whom I have a lot of respect for) in his writings, and applying them to the same application using the Swiz framework. Case in point, developers can use Swiz and still implement design patterns that meet the needs of their specific application. This is not the case at all with most of the other frameworks, with the exception of Mate probably.
Awesome article Ben! Thanks so much for proving perspective on another pattern AND example code to boot! Love it. I’ve used the Presentation model with Cairngorm quite a bit in the past and although I won’t be switching to Passive View anytime soon, I appreciate your thoughts on it none the less.
I’m in the process of creating a Flex social networking application (more to learn Flex 4 and Swiz than anything else) and I chose Swiz purely because of the exuberance shown by those that believe in it, such as yourself. Thanks a bunch.
You’re very welcome, Erich! Good luck on your project and be sure to hit up the mailing list (http://groups.google.com/group/swiz-framework) with any questions or comments.
[...] there are other examples of the PV + Swiz out there, like Ben Clinkenbeard’s example, but I went ahead and created an AbstractViewMediator that takes care of some race conditions when [...]