A better world with a better switch statement

It is known that using switch statements should, in most cases, be replaced by polymorphism when using object oriented languages (refer to Clean Code by Robert Martin, Code Smell G23).

But you must stay pragmatic as well, and sometimes the switch statement is an option. But: why must it's C# syntax look like this? Why is it so inconsistant with the rest of the language? Why do we have to write break?

I imagine a switch-statement like this:

switch (selector)
{
  case (value)
  { ... }

  case (other value || still other value)
  { ... }

  case (new List<>() { a, b, c })
  { ... }

  default 
  { ... }
}

So no ':' that reminds me of lables. No break after each case - use the well known block delimiter instead. Write the argument to the case keyword in braces as like with if, while, for and others. Do not stack control structures but use known logical operators / lists to combine cases.

Would this not be nice?

Get hold of the view in the view model

The Problem

Triggered by a tweet from Vaughn Vernon about the question on how to get a reference to the view in a view model I decided to post the solution I used for this.

In general it is not a good practice though, but I needed it sometime as well (mostly because of some part of the system that was not designed with MVVM in mind).

The Solution

I defined an interface for the view and let the view implement it. The interface contains a a reference to the view model through an interface. The view model resides in the views DataContext so we route the property to this:

public interface IView
{ 
  IViewModel ViewModel { get; set; }
}

public partial class View : UserControl, IView
{ 
  public IViewModel ViewModel 
  { 
    get { return DataContext as IViewModel; }
    set { this.DataContext = value; } 
  }
}

The interface for the view model contains a reference to the view through its interface.

public interface IViewModel
{ 
    IView View { get; set; }
}

public class ViewModel : VMBase, IViewModel
{ 
    public IView View { get; set; }
}

Now in the XAML of the view I wire up the view model

<UserControl>
    <UserControl.DataContext>
        <local:ViewModel />
    </UserControl.DataContext>
</UserControl>

In the loaded-event of the view I set the reference back to the view model:

public void Control_Loaded(Object sender, EventArgs e)
{
  if (ViewModel != null)
    ViewModel.View = this;
}

And thats it.

What I like about this solution is that your view / view model know each other only by means of an interface, which gives you a certain amount of decoupling. But it is quite a bit of additional code...

The Drawbacks

As I mentioned earlier it is generally not a good practice to try to do this. Mostly it points to the fact that the system is not MVVMable - but sometimes reality knocks at the door...
A problem with this apporach is timing. If you need the view reference say in the constructor of your view model you wont be successful with the above technique. But you can use it in commands or any time after the view was loaded which was always sufficient for me.
Finally I don't claim that this is a general purpose solution to all cases one might want to use this - it is just what did the job for me.

Maybe it might be helpful to someone else...

Unit Testing and static methods

Miško knew since 2008 what I stumbled about today: you have a hard time if you try to test things using static classes / members.

My case was similiar to this one:

public static class SomeFactory
{
  public ISomeObject Create() { // do nasty things such as service calls }
}

public class ThisIsWhatIWantToTest
{
  public void AMethod()
  {
    // ...
    var someObject = SomeFactory.Create();
    // ...
  }
}

I wanted to write tests for AMethod but I had a hard time. Acutally I could not manage to find a seam to work around the service call easily.

Another thing I noticed along the way is, that static things obscure the dependencies in the code. This is not a good thing because it makes the code harder to understand. If you have dependencies, the should be widely visible for the sake of clarity.

I will very carefully consider the use of statics from now.

Cheers,
Tobias.

Incremental Builds with TFS

A very handy TFS feature is kind of well hidden in the settings. The setting is so "tiny" that I did not find it for a long time. But first things first.

The task: set up a team build that compiles only those assemblies that have been modified since the last build. You can call this an incremental build.

The whole magic is the "Clean Workspace" parameter in the build definitions process tab. Here one can choose how the build handles its workspace. You have three choices:

1. All: Delete Sources & Binaries, then get all and build all. This is a complete rebuild. This is the default
2. Outputs: Delete the binaries but keep the sources. Gets only the sources that have changed (incremental get). Recompiles all the sources so you get a full set of binaries.
3. None: Delete nothing. Gets only the sources that have changed and rebuilds only assemblies that have changed. 

Option three is the one that does the trick. If you trigger a build, than change something and trigger another build, your drop location will hold two folders. You will see all the files in both folders but dont be disappointed. All files are moved to the drop location, but mind the changed date: they are all different.

This way you can figure out easily what has acutally changed. This comes in handy if you want to ship hotfixes that only contain files that have really changed to keep installing the hotfix quick.

Have a nice build ;-)

Tobias.

Code Quality mit Visual Studio und TFS

Besser spät als nie, hier die Slides und Beispiele zu meinem Vortrag "Steigerung der Codequalität mit Visual Studio und TFS".

Bei Fragen und Anregungen gerne melden.

Viel Spaß und viel Erfolg beim clean coden :-)