Small things - Select Rectangle of Text

I found something really small and simple, but it's changed my world (ok, slight hyperbole). While most C# developers already know about it, for some reason I'd never come across it.

It's possible to select a rectangle of text with Visual Studio. And all you have to do is hold down alt while you're holding down the left mouse button. Easy peasy! This is especially handy when you're using something like Specflow and you have tables of data you're updating. Give it a go, it's awesome.

ViewModel Properties (3 of 3)

In part 3 I'm going to take what we've done with ViewModel Properties and show you how it dove tails very nicely into testing.

I use Specflow as my Gherkin tool of choice (you will need to install it if you want to play with the example). I won't go into detail about the philosophy of BDD and Gherkin. If you want to do some reading you can go here and here. But in short I've used it on several projects and I'm starting to think it's a pre-requisite for any large project.

Before we go any further here is a peek at one of the Gherkin tests. You'll see they are very simple and easy to read (even a BA with no coding ability would be able to understand it). For each Given/When/Then line there is a method in code that handles the step. It all takes a bit of getting used to but it's very much worth the effort!

Let's take a look at why our ViewModel Property helps us with testing. If you recall, we have a ViewModel Property Collection within our ViewModel to help us keep track of and manipulate our Properties as a whole. What this also gives us is a method called GetSnapshot. This method will return a Dictionary (key/value) with all the relevant data for a Property (it just iterates over all the ViewModel Properties and calls GetSnapshot on them). With this data we have a snapshot of the state of our ViewModel.

From there setting up the tests becomes relatively trivial. You create the tests using actions applied to your ViewModel and expected states of your ViewModel as validation (that's all testing is really, perform an action and validate the state of the object we're testing). If you're using BDD you could create Acceptance Tests off the back of your Specifications. If you're using TDD, you would create all the test scenarios before you've written any code.

Obviously there is a lot I haven't discussed here. The best way to learn about something is to get your hands on it and dive right in. So please, if you are interested in this approach, go to the GitHub repository, and have a play. And of course, any feedback would be appreciated!

ViewModel Properties (2 of 3)

It's time now to go over an example of how we could use our funky new ViewModel Properties. I've created a very simple Person example. In fact it's so simple you'll have to forgive me. There is no dependency injection and I'm creating a ViewModel in code behind, but it's all just to get the point across.

Lets look at PersonViewModel (or the start of it as seen above). You'll see on line 13 I'm creating an instance of the Collection. Then lines 15 to 20 are the Property definitions. And then at the bottom the constructor takes the Controller as a parameter and calls Initialse. All very clean and easy. So what happens in Initialse?

This is where the fun begins. We're creating all of our properties and specifying their behaviors. Lets look at Age (line 47) as a good example. The New method has to specify Name and the default "getter". This is the bare minimum. Next we add a description which can be used (and is in the example code) for binding to a TextBlock, then we set it to not be editable and we specify the format. And finally we call the Build method to return the built ViewModel Property.

Now how would the binding work?

PersonView is very simple, just a few TextBlocks and TextBoxes binding to our ViewModel Properties. You can see that all the TextBlock "labels" bind very nicely to the description of the Property. You can also see that each TextBox binds very nicely to the Value of our Property or in the case of Age to the FormattedValue of our Property. It can also very easily be made ReadOnly by binding to IsEditable (although you do need a converter that inverts the value). For fun I've also added something to display when City or occupation are updated and when they're invalid.

As (I hope) you can see the xaml becomes nice and clean and declarative, as it rightly should be. There are no string literals in the xaml because we're binding everything to our ViewModel, including any labels. The ViewModel completely defines the View.

I really like this approach because it seems to make everything that little bit neater. It appeals to the OCD in me. But in my opinion the greatest advantage to this approach will be addressed in my next post: testing.

P.S. You may have noticed that I haven't mentioned anything about the Commands in the ViewModel. They're using a similar approach I'm just not going into them to keep the post lighter. But feel free to take a look at it in the code.

You can view all the code here.

ViewModel Properties (1 of 3)

My previous post discussed using a Controller in conjunction with the standard MVVM pattern. One of the reasons for this approach is to simplify/clean the ViewModel. Another way I've found to do this is by using a class that represents a ViewModel property. Quite often when binding to a property on your ViewModel you require the property, whether it's enabled, whether it's been updated, it's visibility, etc. What if you could abstract all of this into a simple and easy to use class. Enter the ViewModelProperty (I know, not the most creative name).

As you can see this provides us with the Value, a formatted version of the value (if a format was set), validation, visibility and editability. It also removes the need to inherit from INotifyPropertyChanged in every ViewModel (although I guess you may still need to for other reasons). It's encapsulated everything into a single class.

I've also incorporated a Builder class and a Collection class. The Builder allows the user to create a property in a fluent manner (looks very pretty in code) and the Collection allows the ViewModel to view and act on all the ViewModel properties that are created. For example, let's say you want to reset all changes made to the properties, you could simple call ResetValues() on the Collection and it will do all the hard work by resetting each property instead of you having to manage it. Or you could very quickly check the validity of all the updates to your ViewModel properties through the IsValid property on the Collection.

You can view all the code here.