Pixata Custom Controls
For Lightswitch

Recent Posts

Popular tags (# posts in brackets)

Anonymous types (3) ASP.NET (5) C# tricks and tips (2) Computers (4) Design patterns (3) DomainDataSource (3) Dynamic data (4) Entity model framework (7) LightSwitch (12) Linq (6) Microsoft (2) MVP (2) MVVM (2) RIA services (5) Silverlight (2) SQL Server (1) Unit testing (4) Visual Studio (5) WCF (3) WPF (2)

Archives

Categories

Blogroll - Fav Blogs

Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Actually, as I'm self-employed, I guess that means that any views I expressed here aren't my own. That's confusing!

About me

Acknowledgments

Theme modified from one by Tom Watts
C#/HTML code styling by Manoli

My rambling thoughts on exploring the .NET framework and related technologies
Home of the surprisingly popular Pixata Custom Controls For Lightswitch (well, it was a surprise to me!)

# Easing web development with WebFormsMvp (Monday, July 11, 2011)
 

Always on the lookout for ways to improve my coding efficiency, I was very interested to hear about WebFormsMvp, which is a framework for writing ASP.NET web sites, based on the MVP design pattern. This post describes my initial frustrations, and eventual delight in using the framework.

In a future post, I intend to describe how to get going with WebFormsMvp, as well as how I extended it to reduce the boilerplate code even more.

Categories: ASP.NET | Design patterns | MVP | Unit testing

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.

You could call the message box from the VM code, but this breaks the MVVM pattern, and is a really bad idea if you don't want people sneering at you in the street. It also stops you unit testing your code, which is inconvenient, but nowt by comparison to the derisive looks.

What you can do is not bind the command method, and handle it all in the button's click event. If the user confirms their desire to destroy the world, you just call the command method on the VM manually. However, doing this loses the benefits of the ABCCommandCanExecute() method. As this feature is pretty neat, we don't want to lose it if we don't have to.

Thankfully, we don't. After that long and drawn-out preamble, we are proud to present a surprisingly simple solution to the problem (drum roll please)...

This is based on the (apparently reliable) fact that a button's click event is called before the command is sent to the VM, giving us chance to get in the way.

We create a Boolean property (capital B in deference to the dear, departed George Boole, inventor of most of modern mathematical logic - the good bits anyway!) that will specify whether or not the command is to be executed. Here is some sample code for the VM...

public bool WasISure { get; set; }

Pretty complex stuff eh? Now, in the code-behind of the view, we have code like this...

private void button1_Click(object sender, RoutedEventArgs e) {
  bool wasISure = (MessageBox.Show("Are you sure?", "Confirm", MessageBoxButton.YesNo) == MessageBoxResult.Yes);
  ((MainViewModel)this.DataContext).WasISure = wasISure;
}

The code above assumes that your VM is called MainViewModel, and is bound to the DataContext of your view. If not, you just substitute your own code for getting hold of the VM.

When the user clicks the button, the click event is raised first, and this shows the message box. The result (ie confirmation or refusal to destroy the world) is shoved into the VM's Boolean property, where it can be used by the command method to determine whether or not it is to execute...

private void DestroyTheWorldCommand() {
  if (WasISure) {
    // destroy the world here
  }
}

That's it really! A great long piece of waffle for a few lines of code (more for those modern types who insist on putting their opening braces on a new line, but still not many). Best of all, it doesn't break the fab MVVM pattern, allowing you to hold your head up high next time you go down the pub and brag about how clever you are.

Categories: Design patterns | MVVM
# Design patterns (Sunday, December 19, 2010)
 

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!)

Categories: Design patterns