Excursus: Supervising Controller Pattern

Note: This is the second preparation post for an upcoming MVVM related post (which got definitely too long)….

The Supervising Controller pattern (previously known as Supervising Presenter pattern) goes back to Fowler ([Fowler-SC]). What makes it relevant for Silverlight development is that it is the usually employed pattern.

Similarly to the Presentation Model (PM) pattern, the Supervising Controller pattern essentially contains three parts: View, Model, and Supervising Controller (SC). The SC pattern provides “the ability to easily map between the view and model, often using some kind of Data Binding”. The mediator between the View and the Model is the SC: “A Supervising Controller has two primary responsibilities: input response and partial view/model synchronization.” ([Fowler-SC])

While the SC pattern is very similar to the PM pattern, the relationship and responsibilities of the parts are somewhat different. For an SL application it looks like this:

Compared with the PM pattern, the difference is seemingly minor: The SC lacks the responsibility to establish a data model, rather there is an additional arrow from View to Model. However, this is actually (at least in comparison to the PM pattern) the defining characteristic of the SC pattern: The View interacts directly with the Model (contrary to the PM pattern). The SC acts only as a mediator, once the connection between View and Model is established, the SC is no longer involved.

The SC has the following responsibilities (leaving aside view entities, as they constitute only a minor part of the data model):

• Handling the controller logic part
• Talking to the service

Obviously the SC as less responsibilities than the Presentation Model, resulting in less complexity, and better separation of concern. On the other hand it is also less flexible and thus less applicable in complex cases.

The Relation to MVVM

Matter if fact, this is the way MVVM for Silverlight is usually presented: If you find a more recent description of Silverlight with MVVM (which is curiously not that easy), it is probably similar to my own introduction. Dan Wahlin has recently written about the topic, focusing on SL, and it’s probably the most concise introduction to MVVM with SL I’ve found so far. And again, his code snippets and text descriptions clearly follow the SC pattern. (Curiously his images follow the PM pattern, but since he never names it and takes a rather pragmatic approach anyway, I’ll leave it at that. 😉 )

Notwithstanding the verdict: From a purely formalistic point of view, this is simply wrong! If MVVM is defined as a derivate of the PM pattern (as it was originally introduced), it cannot follow the SC patter at the same time. Both patterns follow contradictory approaches regarding the data model and the resulting ViewModel responsibilities. Actually it is even worse: Since it is not even a responsibility of the SC to define a data model in the first place, the term ViewModel is grossly misleading.

However, given that the Model for SL applications is usually code generated and supports everything that is needed for databinding, the beauty of this approach is its ease of use. At first. (In other words, stay tuned…)

That’s all for now folks,
AJ.NET

Advertisement