F#, Xamarin, WPF, Test Automation

Does your View-model Violate Single Responsibility

The majority of us are unknowingly violating the Single Responsibility Principle when constructing our view-models. The XAML below consists of three buttons that when pressed will show a description relative to each button. There is also a clear button to clear all description fields.

This view-model handles state and accepts commands. So what’s wrong with this view-model? Maybe nothing. It provides the necessities that our view requires to present itself and to submit requests. But look deeper into this view-model. What is its purpose? What is it severely focused on or in other words, how well is it focused?

This view-model is handling two responsibilities. It’s reflecting state and it’s also managing requests. That alone violates the Single Responsibility Principle which is meant to protect us from maintenance concerns. How ironic that WPF’s core design principle is to separate presentation from behavior. However, when practicing MVVM, we religiously bloat our view-models to do the exact opposite and end up coupling behaviors with states without giving it a second thought.

An Alternative Approach

What if we could create a mechanism for separating responsibilities of state and behavior? Specifically, why can’t we create a responder to handle view requests and use our view-model to only reflect the state that our views require for presenting? Then, our actual view-model could be a lot cleaner. Thus, we could offload behaviors of our view-model to a more focused class whose sole responsibility is to respond to commands. Now that sounds like a much better solution to what we have currently.

I acknowledge that some people may say that my recommendation adds unnecessary complexity and that adding this complexity does not produce any noticeable value. Their assumptions are valid. At least until several people begin to maintain that same view-model. It is then that the view-model’s complexity skyrockets out of control and slows down developers from making progress. The view-model’s initial purpose becomes obscured with many responsibilities and results in the view-model appearing more like congress (slow, complex, and in debt).Creating a ViewModelBase

Let’s start by creating a base class that will manage databinding notifications.

Next, let’s add a responder . The responder’s core responsibility is to respond to commands. We’ll also use a pub/sub mechanism to perform messaging agnostically between client and server. In this case we use the “Bizmonger.Patterns” package that can be downloaded from Nuget. It provides a MessageBus to accomplish messaging. In this class we will publish messages after we have processed a command.

In conclusion, the majority of us are unknowingly violating the Single Responsibility Principle when constructing our view-models. Our view-models are usually handling two responsibilities. They’re reflecting state and also managing client requests. That alone violates the Single Responsibility Principle which is meant to protect us from maintenance concerns. When practicing MVVM, we unconsciously bloat our view-models with multiple responsibilities which results in coupling behaviors with state information which WPF is designed to protect ourselves against. Instead of accruing this technical debt, we can separate these concerns by creating a separate mechanism for command response and use our view-models to only reflect state for our views to present.

NOTE:

Scott Nimrod is fascinated with Software Craftsmanship.

He loves responding to feedback and encourages people to share his articles.

He can be reached at scott.nimrod @ bizmonger.net

Advertisements

Share this:

Like this:

Published by Bizmonger

Scott Nimrod is fascinated with software craftsmanship. He has been practicing software development since 2003. He’s a thriving entrepreneur, software consultant, blogger, and a wanna-be thought leader. He focuses on native application development and test automation. He was born and raised on the mean streets of Cleveland, Ohio and currently resides in Miami Beach, Florida. He has been featured on DotNetRocks as well as DeveloperOnFire.
Featured Guest:
* http://dotnetrocks.com/?show=1214
* http://developeronfire.com/Podcast/Episodes/scott-nimrod-craftsman-or-prima-donna
* http://joecolantonio.com/testtalks/82-scott-nimrod-software-craftsmanship-revenge-of-the-sdet/
Details:
Scott Nimrod is a Agile (F#, XAML) Developer / SDET focused on enterprise development, mobile, and test automation.
He has worked in Seattle, Cleveland, Miami, Tampa, Ft. Lauderdale, and the Philippines. He hopes to work abroad again in either Asia or South America.
He loves sharing what he has learned.
He can be reached at the following number:
440.376.5867
scott.nimrod @ bizmonger.net
View all posts by Bizmonger