Tag: <span>Design patterns</span>

Like most of us, my applications usually have a global unhandled exception handler, in order that the inevitable unhandled exception won’t crash the system.

The problem with this is that by the time you get to the exception handler, you’ve completely lost the context of what was happening. You’re in an isolated, global context, away from any window.

What you really want is to get immediate feedback when there’s been a problem, so you can react appropriately for the situation. For example, failure to load a customer list could be handled by trying again, up to a maximum number of attempts, before informing the user that the list couldn’t be loaded. By contrast, if they were trying to save an individual customer (presumably from a customer details window), you’d react differently.

Around a year ago, whilst contemplating this issue, I had an idea that turned out to be an excellent answer to the problem. It turned out that this wasn’t an original idea (it was too obvious for that), but as I hadn’t come across it before, I didn’t know that at the time.

In this post, I describe the Fallible type, and how it can be used (really easily) to simplify and improve your exception handling.

A few years ago, I blogged about how to implement an “Are you sure” pop-up in MVVM. Well, I’ve grown up (a bit) since then, and realised that the code there wasn’t testable. I therefore take great pleasure in presenting for your delight, a testable “Are you sure” pop-up in MVVM. Aren’t I kind 🙂

Being good boys and girls, we want to write testable code, so if by some miracle we ever get around to writing unit tests, we can run them safe in the knowledge that they stand a fetid dingo’s kidney’s chance of working! One of the main issue involved here is ensuring we keep all view-related code out of the view model.

This post explains how to do it (with some pointless pictures)

As the non-existent avid reader of this blog will know, I’m far more interested in learning new technologies than I probably should be, given the limited amount of time I have to learn them properly! With that in mind, I shouldn’t be looking at yet another, but this one does have a very immediate benefit (honest).

I have been an ASP.NET developer for quite a number of years, and can knock out a complex web site fairly quickly. However, as with most of my other programming until recently, this has always been along the “throw it all in the code-behind” anti-pattern. I’ve come a long way in the last six months or so, and am now very comfortable using MVVM in WPF, and separating out my code into logical classes as all the Good Programmers do.

Logically therefore, my web site development should follow the same lines. I read up on both MVC and MVP, and came to the conclusion that as an experienced ASP.NET developer, MVP made a lot more sense to me. I couldn’t honestly see any technical benefit of one over the other, mainly as the MVC proponents seem to raise the same old “webforms are evil” arguments, without any real justification (to me at least, they obviously feel justified). My own feeling was that MVP wins out because it completely isolates the view from any action, meaning that the view is as dumb as it can get, which makes unit testing a doddle. I was won over towards the Passive View version of MVP, as this has even less code in the view than the other flavours.

This is not to say there’s anything wrong with MVC, just that I feel more comfortable with MVP.

This post details my initial exploration of WebFormsMvp.

A common scenario is to have a button on a view that is bound to a command on the viewmodel. You can also have an ABCCommandCanExecute() method on the VM that tells the view whether or not the button can be clicked.

This is all fine until you want to ask the user to confirm the action that will be performed when they click the button. For example “Are you sure you want to reformat your hard disk, dial up all the people in your contact list and reformat their hard disks, and then destroy the world?” It’s kind of rude to do this without confirmation first.

The problem is that when you use WPF binding to bind the VM’s command method to the button’s Command property, you lose control over the execution process, and so can’t inject a message box into the flow.

Although it’s not actually a .NET issue, I decided to blog about it anyway!

I’ve been looking at design patterns quite a lot recently. I have always been a “bung it all in the code-behind” kind of programmer, which is an easy way to program, but messy. You end up with spaghetti code that’s hard to maintain and impossible to test automatically (not that I ever tried mind you!).

I decided to learn some new skills, and discipline myself to programming the Big Boys’ Way. I dutifully went to Amazon and spent far too much on books, and sat down to read them all. Most were fairly tough going and dull. I was beginning to think it wasn’t worth the effort, until I came across Head First Design Patterns, which was a breath of fresh air. Apart from the slightly wacky style, the explanations were very good.

My only gripe with the book is that it’s very Java-oriented. Given that design patterns are language-agnostic, this is totally unnecessary. Most of the time it didn’t spoil the book, but in a couple of places it really annoyed me. However, it’s still the best design patterns book I’ve read by a long way.

I hope to blog more about this subject. Watch this space (unless you’ve got anything better to do of course!)