Simplified MVVM Commanding with DelegateCommand
The MVVM (Model-Miew-ViewModel) pattern for WPF works really well, but for me has one big disadvantage – the sheer verbosity of it. There’s just so much code to type! Especially when you’re going for the ‘pure’ approach of no code in your code-behind.
One of the worst offenders for this is the Command model, whereby in your ViewModel you define a class which implements ICommand. This is made available to the View via a property, and when called, calls some method in your ViewModel.
(Note: This only applies to WPF. Silverlight doesn’t currently support commands in the same way.)
Here’s an example, from inside my ViewModel (MeasurementViewModel):
(This is set up in the XAML as follows:)
You can see the custom ICommand (AddDefinitionCommand), a local variable to hold it, and a property getter for the view to find it. Now considering that this doesn’t even have the code which performs the action (which is viewModel.AddMeasurementDefinition), that’s lot of overhead. And you have to do that for every single command! That’s button clicks, selection changes, and so on.
One of the problems is that the Command model provides a lot of flexibility by defining the CanExecute() method and CanExecuteChanged event, but I don’t need those in my simple scenario.
So, how to write a bit less code? Of course, you could make some good use of Code Snippets, but there are better solutions. The best one I’ve found is the DelegateCommand approach used in Microsoft’s Composite Application Library (a.k.a Prism), also discussed in Josh Smith’s MVVM article (where he calls it a RelayCommand). This involves defining an ICommand which uses delegates, and means you have less boilerplate code to write.
As I’m not interested in using the full features of the ICommand, my simple DelegateCommand goes like this:
DelegateCommand.cs
And to call it, you simply need the following:
You can see the local member for the DelegateCommand, the ViewModel constructor where we define the method to call, and the property to make it available to the View. Much simpler, I’m sure you’ll agree!
Of course, if you want to include the rest of the Command functionality, you can just extend the DelegateCommand. So there you have it, all of your MVVM problems solved! Well, nearly..
The Code
(As I don’t seem to be able to upload DelegateCommand.cs for you to download, here’s the text for you to copy & paste. I’ll work WordPress out one of these days…)
WCF Overview
I did an introductory WCF workshop the other week so I thought I’d post the basics here. This diagram shows the usage of WCF (excuse the crappy PowerPoint art) – brief explanations below:
WCF Usage Diagram
Service
This is your actual service, which is just made up of standard .Net code, usually an interface and the implementation. The interface has a couple of attributes on it to make itself known to WCF as a service, e.g.:
In VS2008, you can create this by adding a new ‘WCF Service Library’ project, which includes some example code.
Host
The host is whatever runs the service, making it available on a particular address. In most cases this will be IIS, but it could be a Windows Service or even just a console/winforms app.
Either way, you’ll need some config to specify the Address, Binding and Contracts (known as the ABC), which in it’s most basic form will look something like this:
These are collectively known as an ‘endpoint’. If you created a WCF Service Library for your service, Visual Studio will actually have created this for you in an App.config file, which you can just copy into your host application.
Then to run the service, just stick this in your main():
Client
Here’s where you actually call your service, again just a standard application of your choosing. The point at which it turns into a WCF client is when you select ‘Add Service Reference’ in Visual Studio, and give it the address of your running service. This does a load of magic, and the important things you and up with are:
- A config file with the relevant WCF endpoint in it
- A service proxy
The proxy is basically a local version of the service that you created. If you look at all the files in the service reference, you will see ‘reference.cs’, which contains your service methods. When we want to call the service from the client, we just make a call to this proxy, which goes away and handles all of the tricky networking stuff in the background so you don’t have to worry about it.
How simple is it? Here’s the code:
Conclusion
So, WCF’s pretty easy to use. The main issue you’ll face are probably with config, and firewalls (addresses not matching, remote machines not responding, and so on). Once you get into it, WCF’s a massive technology, but at a basic level it’s pretty straightforward.
Apologies if this was a little short, but I thought it was about time to feed the blog! Feel free to get in touch for more details.
Podcast Rundown
One of my favourite ways of keeping up with development is listening to podcasts, which I usually do in my car – a stereo with a USB port comes in very handy here. (Note: Only do this while alone! The dulcet tones of Scot Hanseman might increase your knowledge, but they’re unlikely to impress the chicks..)
Anyway, audio tips and sexism aside, here are all of the podcasts I’ve been listening to and what I think of them, in order of greatness:
Rating: 10/10
Technology: Mainly .Net
Sound Quality: Average
Hosted by four smart and fairly amusing guys, the beauty of this podcast is that you always get to hear all sides of the argument on any given topic. And unlike some of the other podcasts, the topics are nearly always interesting – I rarely skip an episode. They get some top guests too.
Rating: 9/10
Technology: .Net
Sound Quality: Excellent
Probably the best-known and longest-running podcast out there, .Net Rocks is perhaps the most professionally produced show out there – you could easily mistake it for a radio show. The presenters are funny and knowledgeable, get good guests and always ask pertinent questions (although you don’t get the same level of discussion as with Herding Code).
Rating: 8/10
Technology: Mainly .Net
Sound Quality: Poor – Average
Run by some of the ElegantCode bloggers, this podcast is similar to Herding Code in it’s style, usually with multiple presenters leading to interesting discussions. It seems to have died since David Starr left for the PluralCast (see below), but I’m hoping it might get resurrected.
Rating: 7/10
Technology: Mainly .Net
Sound Quality: Average
Although this only lasted a short while, the few podcasts it created covered some really useful subjects, in good detail. And being Alt.Net (if you’re aware of that movement), there are also some interesting debates and disagreements in there. Well worth a listen.
Rating: 7/10
Technology: .Net
Sound Quality: Good
Having recently taking over from the Elegant Code Cast, the Pluralcast has made a good start, covering some interesting subjects. Although run by a commercial company (PluralSight Training), the shows don’t feel like they’re trying to sell you anything. The interviews are sometimes a little one-sided, and the shows don’t always flow as well as they might, but definitely one to try out.
Rating: 6/10
Technology: .Net
Sound Quality: Excellent
Alongside .Net Rocks, HanselMinutes is the other well-produced, long running podcast. Scott is currently a Senior Program Manager at Microsoft, which means he gets some great guests and inside scoops, but sometimes the interviews are again a little one-sided. Scott’s a really smart guy and knowledgeable developer, and I feel bad for only giving a 6, but the subject is often web development (which I’m not really into), and I often skip shows because I’m not that interested in the guest/subject.
Rating: 6/10
Technology: All
Sound Quality: Good
I’ve really only just started listening to this so it’s a little early to give my opinion – but when did that ever stop a reviewer?! So, as you might imagine from the title, it covers general software engineering in all languages, often with clever academic people being interviewed by other clever academic people. Ok, perhaps I undersell it there, it’s not all academic – and it is good to break out of .Net every now and again.
Rating: 5/10
Technology: .Net
Sound Quality: Average
A show run my a couple of Microsoft evangelists, this has some good content, but the shows are fairly infrequent and I often skip them. The subjects and interviews can be a little Microsoft-heavy.
Rating: 5/10
Technology: All
Sound Quality: Good
Run (although not hosted) by The Pragmatic Programmers, this podcast consists of interviews with the authors of various books on the Prag Pub label. It’s kind of commercial in that respect, but interesting nonetheless.
Rating: 4/10
Technology: .Net
Sound Quality: Good
Again I feel bad about giving this such a low rating, as it’s not a bad podcast, I just don’t like it personally. I only listened to the first few, but the topics are usually web-based, and were often covered fairly simplistically, and I didn’t really like the presenter. I think I’ll give it another try soon, as everyone else seems to rate it.
So there you go, plenty to keep you occupied on your lonely commute there! Obviously those ratings are just my opinion, so don’t take my advice – go and try them for yourself!
WCF Speed Test using Multiple Endpoints
One of the cool points about Windows Communication Foundation (WCF) is that it lets you change the type of connection you’re using without changing any code. All you need are a few config changes, and hey presto! You can go from HTTP to Named Pipes faster than David Blaine can escape from a lead box full of snakes.
At least that’s the theory. Being so easy to change ‘bindings’ as they’re known in the world of WCF, I thought I’d do a bit of test to see how fast some of the these bindings were. There are many bindings to choose from, but in this case I’ve gone for HTTP (standard protocol for web services – quite verbose, with data transferred as XML), TCP (which is similar to HTTP but has a more compressed, binary data transfer) and Named Pipes (which is normally used for inter-process communication, so should be very efficient).
Using Multiple Endpoints
Although not strictly necessary for this test, one thing I wanted to try was to define a service which had several different bindings at the same time. The idea with this is that you can have a single service, but connect to it in multiple different ways – for example, use Named Pipes to call it from the same machine, TCP from within your own network, or HTTP for anything external. Or maybe you want to offer different SOAP versions for clients of differing advancement. For my test, this means I can have a single service and a single client, and connect using whatever binding I like to do my speed measurements.
So, to begin with, I created my service and added a standard HTTP endpoint along with a MEX endpoint so I could easily create the client from it. (In this case, I’m hosting the service in a simple console app host which I created). I created the client proxy using the ‘Add Service Reference’ functionality in VS2008, got that working, and then set about trying to update the config files to enable different binding types.
As it turns out, this is actually very easy. To enable this at the service end, you simply have to add some endpoints and corresponding base addresses to your config:
Specifying multiple endpoints on the service
You don’t even need to tie them up, or do anything different in your code – to start the host it’s simply:
Starting the service host
And bob’s your uncle! Add a bit of a printout on the host to get the service details, we now have the following (notice the three addresses with different ‘Schemes’):
Service host details
That’s the service sorted – so what about the client? Well, in the normal case of the client connecting to only one service, we’d just need to put the corresponding endpoint details in – but as I want to connect to all three endpoints from the same client, I put all three in:
Client configured for multiple endpoints
You might notice here that I’ve stripped the config file down to the bare bones, by removing all of the specific HTTP configuration and the MEX endpoint, just to make things clearer (although this config works fine and is what I used for the test).
In terms of opening the client, again because we’re using multiple endpoints, I’ve had to tell it which one to use by referring to the name I gave the endpoint in the config file:
Starting the client for a specific endpoint
So I’ve done this for each of the endpoints. Of course, if I’d wanted to be clever I could have read the names from the config file and not had to be so specific in the code – but it’s Sunday, and Top Gear’s on soon.
So that’s it! I now have a service which you can connect to over three different protocols, and a client which can use them all – and David Blaine got out ages ago…
The Speed Test
So onto the speed test. First, I’ll give you a little info about how it was done (although don’t be fooled into thinking this is in any way scientific or tightly controlled).
I created two methods, one passing a simple data type and one a more complex data type:
Service contract used for the speed test
These methods don’t do anything except pass back the data that was passed in.
Performing the tests was simply a case of calling both of these methods in a loop once, then 10 times, then 100 times each. I also did one ‘warm-up’ call to each method before starting the timing, as WCF services take a little while to get going the first time. This was all done on my local PC, there was no networking involved.
I timed all these calls using a stopwatch, calculated the average, and that’s about all there was to it.
So, you want to know the results? Very well, but I have to give you a number of disclaimers first:
- These results are using a WCF host not IIS, which could make quite a difference
- I haven’t optimised any of the connections (e.g. by putting parameters in the config file)
- The first call was not timed, so if you’re only calling a method once, this won’t mean so much to you
Essentially, this boils down to the standard advice for performance testing – you need to try it yourself, with your particular environment and setup, making the kind of calls you make, to get any meaningful numbers. And with that, here are the meaningless numbers!:
Speed Test Results
You can see the final averages at the bottom there. Pretty much what you might expect – Named Pipes was slightly faster than TCP, both of which were considerably faster than HTTP.
Of course, it’s all in milliseconds so really not worth paying a lot of attention to, unless you happen to be making hundreds or thousands of calls – and even then, your choice is likely to be made based on security issues, what kind of network you’re using, and the types of client connecting to your service.
So my time’s been pretty much wasted then… Never mind, it’s time for Top Gear now anyway.
Closing a WCF Client – The Proper Way!
I’ve finally gotten around to putting a bit of time into Windows Communication Foundation (WCF), more of which to follow.
There’s one particular ‘feature’ I came across which doesn’t seem too well advertised, which I though would be worth sharing, related to how you close the connection.
Now, with most things in .Net that implement IDisposable (database connections, network connections, and so on), you simply have to call Close() or Dispose() – or more commonly, just put them in a Using statement:
Closing a WCF client implicitly with a Using statement
The problem with this approach when it comes to WCF is that, unlike most things that you can Close(), when you call Close() on a WCF client, an exception might be thrown:
Exception during WCF client close with a Using statement
If you don’t know about the Using statement, it just calls Close() for you at the end of the code block so you don’t have to remember it. You can see the same thing happening here using Close() explicitly:
Exception occurring on WCF client Close()
So, what’s happening here? Well, unlike some of the other things you might call Close() on, the WCF client is doing some actual work in this method. For a start, it’s connecting back to the service, which is something that could always fail due to network problems and so on – in the example above, I simply stopped the service before the client was closed. There may also be transactions to be finalised, and many other things I don’t know about.
But do we really need to care? Well, it’s hopefully not something that will happen a lot, but knowing the systems I’ve worked on, I’m sure it will happen at some point. And the chances are, you don’t really care about this exception – you’ve finished using the service anyway. So although it may be something you want to log, it probably isn’t a good enough reason to stop your app running, or disturb the user with a random message. It also means that your connection hasn’t been closed down properly, which could cause problems.
‘So what’s the fix already?!’, I hear you cry. Alright, I’m getting there! In the basic case, it’s as simple as putting a try-catch around the call to Close(), and calling Abort() on the client if something bad happens (which will make sure everything’s cleaned up properly):
A better way to close a WCF client
And if you want to go the full hog and get one more tick in your ‘best practices’ box, you can follow this pattern (as pinched from Steve Smith’s blog):
The Proper way to close a WCF client
Obviously, you can add logging in as appropriate.
This is admittedly a bit of a hassle, but you can always put it into a helper class or, as Steve suggests in the above blog, write an extension method on ICommunicationObject which will then work for all of your clients. I haven’t tried this, but it seems like a good approach.
So there you have it – one less thing to worry about with WCF! (Or is that one more thing to worry about..)
The General Principle of Software Quality
I’m reading Steve McConnell’s excellent book Code Complete at the moment, which is packed full of useful information. One thing that particularly jumped out at me is the General Principle of Software Quality. I’ll get straight to the point, although perhaps a bit of ‘X Factor’-style suspense will spice things up a bit:
The General Principle of Software Quality…………..
Is………………………………
Improving Quality Reduces Development Costs.
This simple but counter-intuitive statement has a potentially massive impact on the way you write software. The basic premise is that in most software development efforts, finding and fixing defects takes up a large proportion of the construction time, and so writing high-quality code with minimal defects from the start, even though it may require a little more effort upfront, is one of the best ways of reducing the total development time. (Because as we all know, time is money!)
This being Steve McConnell, of course, everything is backed up by hard data and studies, in this case including NASA’a Software Engineering Laboratory, which found:
.. quality assurance was associated with decreased error rate but did not increase overall development cost
and a study at IBM:
Software projects with the lowest levels of defects had the shortest development schedules and the highest development productivity… software defect removal is actually the most expensive and time-consuming form of work for software
If you’re already coding based on this assumption then, as Mark & Lard would say, Carry On! (Of course, it’s always good to be sure you’re right, and have some data to back you up in an argument). But I’ve worked at quite a few places where management and developers alike take the opposite approach – as soon as the schedule starts to get a bit tight, quality is the first thing to suffer, with things like coding standards, testing, and reviews getting squeezed or dropped altogether in an effort to hit that deadline. Unfortunately, this self-destructive behaviour leads to a vicious cycle which is only ever going to cause the project to get into a worse and worse state, getting delivered way later than it needed to (if it ever gets delivered at all).
So, what is quality code and how do we keep it high? There are two main areas which are involved that tend to go hand-in-hand: the structure of the code itself (which should be readable, understandable, and generally maintainable), and the number of defects it contains.
Maintainable Code
Code structure and maintainability is important because, as many people have pointed out in the past, code is read more often than it’s written. Even before the maintenance phase, code is often changed during initial development – functionality is added, defects are fixed, code is refactored, streams are merged. If the code is hard to understand, it’s much more likely that changes will introduce new defects – and this is magnified during maintenance, when a different set of developers are working on the code. And when you consider that Yourdon reports that developers making a small (1-5 line) code change have a shocking 50% or more likelihood of introducing a new defect, you can see why easily maintainable code is so important. I won’t go into detail here about what constitutes maintainable code, but things like well-named variables and routines, cohesive classes and routines (with a strong purpose), short routines, and loosely coupled classes all help. (See Code Complete or any other development book for more details!)
Once you’ve discovered how to write maintainable code, the best tools at your disposal to ensure it’s being done by your development team are to write a set of coding standards, and then hold code reviews to ensure the standards are being met – more on that later. Of course, people can’t write good code if they don’t know how, so getting developers up to speed in the first place (using training courses, pair programming, code reviews, etc) is also important here. And tell them that maintainability is the primary goal of their code, not (for example) minimal lines or performance – you might be surprised how well most developers respond to such goals (which is of course covered in the book, with evidence from yet more studies!)
Defect-Free Code
Nobody plans to put defects in their code, and in a perfect world it wouldn’t be an issue. Unfortunately, in this world it’s a very real issue and one that has to be taken into account at an early stage:
Studies at the Software Engineering Institute have found that developers insert an average of 1 to 3 defects per hour into their designs and 5 to 8 defects per hour into code (Humphrey 1997)
Other studies have shown error densities of between 25 and 100 defects per 1000 lines of code, depending on project size. These defects have many causes – incorrect requirements, design problems, coding errors, mis-communications, changes to poorly understood code, typos, and so on. Although most are caused by developers and appear in the code, defects in the requirements and design are also common and can have a much greater impact, and also have to be dealt with.
So now that we’ve come to accept that defects are a part of life, what can we do about them? A large helping of unit tests lovingly applied using TDD will presumably do the trick? Well, it’s certainly a good start, but only part of the answer according to McConnell. The following table lists some of the activities which can be used to help find and prevent defects (the number shown is the average percentage of defects in a system found by that method):
| Method | Defects Found |
|---|---|
| Informal Design Reviews | 35% |
| Formal Design Inspections | 55% |
| Informal Code Reviews | 25% |
| Formal Code Inspections | 60% |
| Unit Test | 30% |
| Integration Test | 35% |
| Regression Test | 25% |
| System Test | 40% |
There were a couple of things that surprised me about this. The first, as I’ve been concentrating so much on TDD and unit testing lately, was how few of the defects were found by unit testing. Although it’s not as bad as it seems – the numbers for unit testing were actually from 15 to 50%, so done well it can be more effective, and if you have automated unit tests then this will also cover you to some degree for regression testing too, further boosting it’s usefulness.
The second surprising element was how useful code reviews can be, particularly considering how easy to implement and less time-consuming they are compared to full unit testing. Some people recommend code reviews as one of the first things you should implement in a development team (for example Roy Osherove), and based on this it’s easy to see why. Of course, there is a little work involved – get some standards/guidelines in place, decide on a good format for the reviews (the more formal the better, apparently), and so on – but it does seem like quite an easy win for quality. And it works just as well for requirements and design as it does for code! Plus you get the extra benefits of spread knowledge, developer learning, and shared code ownership.
A Strategy for Quality
The important thing to take from this is that no single technique is enough – you need multiple methods to ensure high software quality. Don’t forget that the percentages found are cumulative, so a 50% + 50% detection rate would only find you 75% of the defects. And the different methods also tend to uncover different kinds of defects and quality issues – no unit test is going to point out all the magic numbers being used, for example, and it can be hard to spot an off-by-one error just by looking at the code. Different people also tend to spot different errors, another plus point for some kind of review.
Conclusion
I think you get the message by now. The key point to remember is that you always need to aim for high quality code: Plan your quality strategy by using multiple methods, make sure everyone knows what they are and that quality is a primary goal, and don’t stop doing them at the first hint of a slipping deadline!
Check out this article by Steve McConnell, which covers much the same subject, but with much more authority than I could ever muster.
One more time: Improving Quality Reduces Development Costs! Don’t forget to tell your project manager.
Code Contracts – The Future?
Design By Contract comes to .Net
‘Design By Contract’ (DBC) is something the Pragmatic Programmers are very keen on. Introduced as part of the Eiffel language some years ago, it’s a way of specifying how your classes and methods are used in more detail than you get by simple type-checking.
For example, say you had a method that divided some numbers:
The fact that your inputs are Integers means they can only contain certain values, but in this case if ‘Divisor’ contained zero, you’d have a DivideByZeroException on your hands. A contract would enable you to specify that ‘Devisor’ must be positive, or could not be zero. A more common example might be to ensure that an object passed as a parameter was not null.
You can also specify requirements on the return values from methods, or on objects as a whole – ‘whenever this object is in existence, the Foo parameter will not be null’, that kind of thing. By doing this, you’re specifying a contract with users of your code: ‘If you ensure my method is called with the correct parameter values, I’ll guarantee that the return value will be within the specified range’.
This has never been much of a concern to most .Net developers, because although there are some libraries available that implement a kind of DBC for .Net, they are somewhat limited because they’re not part of the language, and certainly not widely used. Generally, people wanting to implement a simple form of this type of checking would do so with exceptions or assertions:
But that’s all about to change! As of .Net 4.0, currently in Beta 2, DBC will be officially part of .Net, under the name Code Contracts. In fact Code Contracts is available now for VS2008 / .Net 3.5 if you want to get started with it straight away. Originally called Spec#, this has been a Microsoft Research project for a while but previously only worked with C#. Now it’s been fully productionized and added into mscorlib, with additional tools for compilation and static checking, and it’s all integrated into Visual Studio.
So now if we wanted to do the above check, we’d need to add a reference to Microsoft.Contracts (if we’re using vs2008), put a using in for System.Diagnostics.Contracts, and add the following code:
‘Wow’, I hear you mutter sarcastically, ’you’ve replaced an Exception with some slightly different code..’. But there’s more to it than that – for a start, as well as checking parameters, you can specify what a method’s output will be using a contract, and you can also specify that an object of a class will always be in a certain state:
As well as the Contract.Requires() which specifies the valid parameter states, you can see Contract.Ensures() which defines the valid return value of a method, and the method marked with [ContractInvariantMethod] which states that an object of the class must always be in that state. The checks here are pretty basic – you could, for example, check that all of the data items in the return list were valid – but hopefully you get the idea.
So what happens when one of these checks fails? By default, you get an assertion failure, but you can also get a ContractException, or even define your own custom behaviour. You also have the choice of whether the checks should be performed only during development or for the release build. As you can see from the Project Properties screen in Visual Studio, there are a fair few options:
Code Contracts project options in Visual Studio
You might have noticed in the screenshot some options for static checking. The static checker is a clever tool which actually analyses your code during compilation and gives you warnings if it can see something that doesn’t meet the specified contracts. For example, if I tried to call my DataGenerator with an invalid parameter of zero:
I would get the following warnings that a contract check was going to fail, including the location of the problem and the contract check:
Code Contracts Compilation Warning
Good stuff! Although from what I understand, this only works well if you’re very thorough and put contract checks on everything, as validating the code statically like this is a very difficult computing problem.
A few other interesting things that Code Contracts does, which you mainly can’t do with exception-style checking:
- Contracts for interfaces
- Contracts inherited from base classes
- Code Snippets for common situations (e.g. Requires(!String.IsNullOrEmpty())
Aside from the obvious fact that you will find problems with your code more immediately, as Andy Hunt and Dave Thomas point out in The Pragmatic Programmer, the big advantage with doing DBC of any kind is that it makes you think about the valid state of your inputs, outputs and classes. This probably goes as far in improving your code quality as the contract checking itself.
But whether you like the idea or not, as of around March 2010, Code Contracts will officially be a part of .Net, so if I were you I’d start looking into it!
Stack Overflow
