Quickduck

I was looking for a fast, free XML editor today, which could handle fairly large (~100MB) XML files without too much hassle. Previously I’ve used XML Marker for this; it’s fantastic, however it has a fairly clunky interface. I wish SymbolClick would release a more modern version!

Anyway, today I found FirstObject XML Editor and gave it a try; so far it seems great! It’s lightweight (only a single EXE file), and it’s fast. Best of all, it has a very, very simple way to format (i.e. pretty print) XML files – just press F8!

Highly recommended.

The problem:

Why can’t I create a List of type Dog and assign it to a List of type Animal?

IList<Animal> animals = new List<Dog>(); // no good

Theory:

There are 3 terms relating to variance:

Covariance – allows more specific types to be assigned to more general types. (i.e. sub-types (classes, interfaces) can be assigned to any types (classes, interfaces) that they inherit from).

C# Example: Method Return types are Covariant. We can return a sub-type of the method’s declaring return type.

IAnimal GetAnimal(string animalName) {...};

GetAnimal("dog") {return new Dog();} // the dog is more specific and returned as the general type IAnimal
GetAnimal("cat") {return new Cat();} // the cat is more specific and returned as the general type IAnimal

Contravariance – allows general types to accept more specific types – i.e. The reverse of covariance.

C# Example: Method parameters are Contravariant. We can call a method with a parameter that is a sub-type of the parameters declaring type.

IAnimal GetAnimal(IAnimal animal) {...};
GetAnimal(new Dog()); // the method takes a general type IAnimal but is called with the more specific type Dog
GetAnimal(new Cat()); // the method takes a general type IAnimal but is called with the more specific type Dog

Invariance – occurs when neither of these conditions are met.

C# Example: In C# 3.0 Generics are invariant. C# 4.0 allows the variance of generics to be defined (with restrictions).

IList<Animal> animals = new IList<Animal>();
animals.Add(new Dog());
animals.Add(new Cat()); 

IList<Animal> animals = new List<Dog>();
animals.Add(new Dog());
animals.Add(new Cat()); // no dice. You can’t assign a cat to a list of dogs.

Here’s a couple (well, one is an overload of the other) of string extension methods I wrote today which I’m quite fond of:

/// <summary>
/// Determines if any of the given matches are a case sensitive match for the
/// nominated string value
/// </summary>
/// <param name="text">The string value to be checked</param>
/// <param name="matches">The list of potential matches</param>
static public bool IsIn(this string text, params string[] matches)
{
    return IsIn(text, true, matches);
}

/// <summary>
/// Determines if any of the given matches are a case sensitive match for the
/// nominated string value
/// </summary>
/// <param name="text">The string value to be checked</param>
/// <param name="caseSensitive"><c>true</c> to perform a case
/// sensitive match</param>
/// <param name="matches">The list of potential matches</param>
static public bool IsIn(this string text, bool caseSensitive, params string[] matches)
{
    StringComparison comparer = caseSensitive
        ? StringComparison.CurrentCulture
        : StringComparison.CurrentCultureIgnoreCase;

    return matches.Any(value => text.Equals(value, comparer));
}

So instead of writing this:

if (name == "James" || name == "Peter" || name == "Sally")
    Console.WriteLine("Your name is too generic!");

You can simply write this:

if (name.IsIn("James", "Peter", "Sally")
    Console.WriteLine("Your name is too generic!");

No offence to the James, Peters, and Sallys of the world.

One thing that I find myself doing all the time is creating some type of base class for my windows/controls in WPF:

namespace Editors {
    public class EntityEditorControlBase<TModel> : UserControl
        where TModel : class, IEntityEditorModel {

        public TModel Model {
            get { return DataContext as TModel; }
            protected set { DataContext = value; }
        }
    }
}

Since this is a generic control you need to specify the concrete type arguments when you subclass it. You can do this in your WPF markup via the x:TypeArguments attribute:

<Editors:EntityEditorControlBase
    x:Class="ConcreteEntityEditorControl"
    x:TypeArguments="Models:ConcreteEntityEditorControlModel"
    xmlns:Editors="clr-namespace:Editors">

    <UserControl.Resources>
        <ResourceDictionary Source="../Resources/EditorResources.xaml" />
    </UserControl.Resources>

    <!-- control content here -->

</Editors:EntityEditorControlBase>

Two important things to note:

• When you want to attach a resource dictionary to the class, you need to do so using the <UserControl.Resources> tag
• In your base class control, make sure you include the [ContentProperty("Content")] and [DefaultProperty("Content")] tags on your class to avoid the horrible “The type ‘{0}’ does not support direct content” error.

This article endeavours to describe how to use the Repository Pattern to abstract and control access (CRUD operations) to a data model locally, through mocks and over-the-wire using the Entity Framework and ADO.Net Data services respectively.

By exposing your Data Access model through a defined interface you can replace your data access implementation to suit your needs whether it be for unit testing or to change the data access frameworks you use.

Background:

Microsoft is pushing the ADO.Net Entity Framework as the ORM of choice going forward.

It’s usually a good idea to get behind Microsoft’s frameworks as you know they will build all sorts of cool utilities and other frameworks on top of them and we all want these goodies. (NOTE: I say usually, because sometimes they cease to support frameworks they’ve pushed before eg. Linq-to-Sql).

The E.F has a number of issues that you will find lots of complaints about on the net, with the most annoying being no support for Persistence Ignorance (i.e. POCOs). However, if you can work around this or are fortunate enough to start a new project where your conceptual model hasn’t been defined yet you might still consider using the E.F.

This article won’t go into the arguments for and against the E.F. and is aimed at people who are happy to head down the E.F. path.

When you use the E.F. you’re next step might be to utilize the RESTful framework they’ve built on top of it called ADO.Net Data Services (formerly Astoria). By simply plugging in your E.F. model you can easily expose portions of your data model over the web via a RESTful nature.

Getting automatic exposure to your data model over http is very exciting due to its simplicity and that universal appeal that any client can interact with your server code.

Let’s get started.

The Repository Pattern:

/// 

/// Generic CRUD Repository operations.
/// 
public interface IRepository : IDisposable
{
    T Single<T>(Expression<Func<T, bool>> whereCondition, params string[] includes);
    Collection<T> Get<T>(Expression<Func<T, bool>> whereCondition, params string[] includes);
    Collection<T> Get<T, TKey>(Expression<Func<T, bool>> whereCondition, Expression<Func<T, TKey>> orderBy, bool ascending, params string[] includes);
    Collection<T> Get<T, TKey>(Expression<Func<T, bool>> whereCondition, Expression<Func<T, TKey>> orderBy, bool ascending, int startRow, int pageLength, out long totalCount, params string[] includes);
    Collection<T> GetAll<T>();
    void Delete<T>(T entity);
    void Add<T>(T entity);
    void SaveChanges();
    bool IsDisposed();
}

First we define the Repository interface. The repository interface exposes a generic set of Create, Read, Update and Delete (CRUD) operations to work against any type of Entity – T.

It’s worth noting that the Get operations take a list of “include” parameters. These “includes” explicitly define which relationship properties to explicitly (eagerly) load when returning the Entity (or collection of Entities) of type T.

For example:

var order = repository.Single<Order>(o => o.OrderID == 10250);

When you call Single on an Order entity the Order entity will be returned; however its Customer property will be null by default.

If you wish to return the Order entity with its Customer relationship eagerly loaded you must specify this explicitly.

var order = repository.Single<Order>(o => o.OrderID == 10250, "Customer");

(NOTE: The IRepository interface has been defined this way for two reasons:

1. The Entity Framework doesn’t support lazy loading of dependent properties (yet!)
2. Because we are using the same interface for local access to a data store and also for access across the wire using ADO.Net data service it’s best to explictly know exactly what you are pulling across
   from the underlying datastore for bandwidth and performance reasons.

)

Now that we have a generic Repository interface it’s simply a matter of creating the implementations you require. You can create any implementation to wrap whatever Data Access framework you want, including Linq-to-Sql, Entity Framework, NetTiers, NHibernate, Sonic, your own framework, etc.

For the purposes of this article, I have created two implementations:

1. An entity framework repository.
2. An ADO.Net Data Service (.Net Client) repository.

The EntityFrameworkRepository implementation works with a VS2008 generated .EDMX ObjectContext instance and utilizes the Microsoft EFExtensions project to add support for SPROC access.

The DataServiceRepository implementation requires ADO.Net Data Services CTP 1.5 to be installed on your machine to utilize query performance improvements (count) and the INotifyPropertyChanged and INotifyCollectionChanged interface implementations on the client proxy objects to implement change-tracking on the entities.

(NOTE: In the future I hope to create a .Net Data Service (Silverlight Client) repository too.)

Once the desired IRepository implementations have been created you may consider creating an IRepositoryFactory implementation to manage the Repository location and lifecycle operations for you.

    /// 

    /// Factory to return instances of .
    /// 
    public interface IRepositoryFactory
    {
        /// <summary>
        /// Get an instance of <see cref="IRepository"/>
        /// </summary>
        /// <param name="name">the name of the repository to return</param>
        /// <returns>an instance of <see cref="IRepository"/></returns>
        IRepository GetRepository(string name);
    }

Access the EF model in-process:

var repository = repositoryFactory.GetRepository("Northwind_Local");
Orders order = repository.Single<Orders>(o => o.OrderID == 10250);

Or to go over the wire:

var repository = repositoryFactory.GetRepository("Northwind_DataService");
Orders order = repository.Single<Orders>(o => o.OrderID == 10250);

Or to mock out for unit testing:

IRepository mockRepository = MockRepository.GenerateMock<IRepository>();
Expression<Func<Orders,bool>> whereCondition = o => o.OrderID == 3;
mockRepository.Stub(r => r.Single(whereCondition)).Return(new Orders() { OrderID = 3 });
RepositoryFactory.SetRepository("Northwind_Local", mockRepository);

IRepository repository = _repositoryFactory.GetRepository("Northwind_Local");
Orders order = repository.Single(whereCondition);

Where to next:

Download the Repository Pattern VS 2008 SP1 Solution.

Install the ADO.Net Data Services CTP 1.5 installer found under /3rdPartyAssemblies/ADONETDataServices_v15_CTP1.exe in the zip file download.

Then set an environment variable dscodegen_databinding value to 1.
This ensures service reference generation in VS2008 uses CTP version and not the old school version. View the video in this link for more info.

Once you are setup, open up the various unit test classes to see how to utilize the various implementations. The EF model is generated against the Northwind database (included as a file reference).

Reference Links:

Persistence Ignorance
http://blogs.msdn.com/dsimmons/archive/2007/06/02/persistence-ignorance-ok-i-think-i-get-it-now.aspx

Repository Pattern
http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx

Repository Pattern with EF

Data Access with Repository
http://blogs.microsoft.co.il/blogs/kim/archive/2008/11/12/data-access-with-the-entity-framework.aspx

Testable Data Access with the Repository Pattern
http://blogs.microsoft.co.il/blogs/kim/archive/2008/11/14/testable-data-access-with-the-repository-pattern.aspx

Entity Framework – Some Common Hurdles
http://blogs.microsoft.co.il/blogs/kim/archive/2008/11/17/entity-framework-some-common-hurdles.aspx

ADO.Net Data Services CTP – 1.5

ADO.Net Data Services Blog
http://blogs.msdn.com/astoriateam/default.aspx

Data Binding (ie.implements INotifyPropertyChanged and INotifyCollectionChanged interfaces)
http://blogs.msdn.com/astoriateam/archive/2009/03/21/ado-net-data-services-v1-5-ctp1-data-binding-overview.aspx

Microsoft EFExtensions
http://code.msdn.microsoft.com/EFExtensions

I really don’t like inefficiency in code. Some people would say I’m quite the coding nazi when it comes to stuff like this; I’m sorry, but I just don’t like having code that exists just because someone thinks “it makes it read more like english”. Sorry, but C# != English.

Don’t get me wrong; I’m all for writing clear, concise code. I strongly encourage using descriptive method names, and fully expressed variable names (e.g. “requestContext” instead of “rc”). But all I’m saying is, don’t over-do it! Here are three small tips you can use to work around small inefficiencies in your code.

Use System.Math
How many times have you come across a segment of code like this?

if (waitTimeMillis < MaxPingTime) {
    waitTimeMillis *= 2;
    if (waitTimeMillis > MaxPingTime) {
        waitTimeMillis = MaxPingTime;
    }
}

Sure, it looks pretty harmless, but we need to read three lines of code to work out that there is an upper limit on waitTime. We can better express that using the Math.Min function:

if (waitTimeMillis < MaxPingTime) {
    waitTimeMillis = Math.Min(waitTimeMillis * 2, MaxPingTime);
}

A boolean is a boolean
I remember one of our lecturers at uni first pointed this one out to me when we were learning java. Comparing a boolean expression to true or false is redundant - just evaluate the expression instead. So, don't do this - ever:

if (MyClass.IsInitialised == true) {
    RunPostInitialisation();
}

No folks, I don't want to see "== true" or "== false" in your code, ever. I guess it could be worse, you could have "!= true"... - either way, lets keep it simple:

if (MyClass.IsInitialised) {
    RunPostInitialisation();
}

Use ternary expressions instead of if/else
Do you really need that if/else clause?

if (house.NumberOfOccupants > 1) {
    house.MaximumNumberOfPets = 3;
} else {
    house.MaximumNumberOfPets = 2;
}

There are circumstances where an if/else clause may be justifiable; but in general, they aren't needed. A ternary expression is much more succinct:

house.MaximumNumberOfPets = house.NumberOfOccupants > 1 ? 3 : 2;

Where the values that you're using for the true/false evaluation of the expression are a bit more complex, you can separate this on to multiple lines to read a bit more clearly:

Type type = Instruments.ContainsKey(instrumentType)
    ? Instruments[instrumentType]
    : UnknownInstrumentType;

Code better!

I have to admit that I much prefer WPF over Windows Forms (but prefer ASP.Net to either). However, the programming model is still a bit immature (in my opinion), and sometimes things that you wish were simple just aren’t. Case and point: trying to programmatically select an item in a TreeView control; it just ain’t easy!

Anyway, after scrubbing the web and finding a few solutions that really didn’t appeal (e.g. using reflection; surely it’s not that hard!) I came up with this extension method which does the trick quite nicely.

/// <summary>
/// Walks the tree items to find the node corresponding with
/// the given item, then sets it to be selected.
/// </summary>
/// <param name="treeView">The tree view to set the selected
/// item on</param>
/// <param name="item">The item to be selected</param>
/// <returns><c>true</c> if the item was found and set to be
/// selected</returns>
static public bool SetSelectedItem(
    this TreeView treeView, object item) {

    return SetSelected(treeView, item);
}

static private bool SetSelected(ItemsControl parent,
    object child) {

    if (parent == null || child == null) {
        return false;
    }

    TreeViewItem childNode = parent.ItemContainerGenerator
        .ContainerFromItem(child) as TreeViewItem;

    if (childNode != null) {
        childNode.Focus();
        return childNode.IsSelected = true;
    }

    if (parent.Items.Count &gt; 0) {
        foreach (object childItem in parent.Items) {
            ItemsControl childControl = parent
                .ItemContainerGenerator
                .ContainerFromItem(childItem)
                as ItemsControl;

            if (SetSelected(childControl, child)) {
                return true;
            }
        }
    }

    return false;
}

(Forgive formatting; the code window is only so-wide.)

The trick, you see, is to use the ItemContainerGenerator on the ItemsControl – which TreeView and TreeViewNode both inherit from – to try to find the container for the item you are selecting. This will only work for the immediate children of the control that you’re calling it on – so asking your root node for the container for an item which is three nodes deep is fruitless; hence, you have to walk down the tree asking each branch node if it contains the item.

It’s possibly not the fastest executing code in the world – walking a tree rarely is – but you could speed things up if you knew where the parent node was; then you could just call the recursive method directly.

Enjoy!

Ever come across some code that just wreaks?

I’m talking the kind of smells like 500 line method implementations or methods that are located in the wrong class.

It’s amusing to see how developers go out of their way to hide their problems rather than fix them.

There are two code-smell hiding techniques I often see utilized in the C# Visual Studio space.

1. Wrap the offending code in a #region (and hope that others don’t have region expansion on by default)
2. Move the distracting/inappropriately placed members into a partial class

Most often though I find that developers seem proud of the smells as they don’t even bother to hide the fact that they’ve just left a big stinky guff for the next person to walk right into.

What code-smell hiding techniques have you been witness to? Or more importantly how do you hide your own smells?

I’ve often seen code that tries to get a numeric bit (1, 0) value for a boolean.

I know of three ways you can do it:

1. Manual condition checking
2. Use the GetHashCode() method
3. Use the built in .Net Convert class

All three approaches do the job however I find that using the Convert.ToByte(boolValue) makes the most sense from a readability stance.

The following examples mix it up a bit and accommodate a Nullable<bool>.

Let’s start with the scenario where true is 1 and false and null are 0.

   bool? tVal = true;
    bool? fVal = false;
    bool? nVal = null;

    // true = 1, false = 0, null = 0

    Assert.AreEqual(1, tVal.HasValue && tVal.Value ? 1 : 0);
    Assert.AreEqual(0, fVal.HasValue && fVal.Value ? 1 : 0);
    Assert.AreEqual(0, nVal.HasValue && nVal.Value ? 1 : 0);

    Assert.AreEqual(1, tVal.GetHashCode());
    Assert.AreEqual(0, fVal.GetHashCode());
    Assert.AreEqual(0, nVal.GetHashCode());

    Assert.AreEqual(1, Convert.ToByte(tVal));
    Assert.AreEqual(0, Convert.ToByte(fVal));
    Assert.AreEqual(0, Convert.ToByte(nVal));

Now let’s mix it up a bit and say that a null value should represent a TRUE or 1 value by default.
i.e. true = 1, null = 1, false = 0,

    bool? tVal = true;
    bool? fVal = false;
    bool? nVal = null;

    Assert.AreEqual(1, !tVal.HasValue || tVal.Value ? 1 : 0);
    Assert.AreEqual(0, !fVal.HasValue || fVal.Value ? 1 : 0);
    Assert.AreEqual(1, !nVal.HasValue || nVal.Value ? 1 : 0);

    Assert.AreEqual(1, (tVal ?? true).GetHashCode());
    Assert.AreEqual(0, (fVal ?? true).GetHashCode());
    Assert.AreEqual(1, (nVal ?? true).GetHashCode());

    Assert.AreEqual(1, Convert.ToByte(tVal ?? true));
    Assert.AreEqual(0, Convert.ToByte(fVal ?? true));
    Assert.AreEqual(1, Convert.ToByte(nVal ?? true));

Is there an easier, better or another alternate way to do this?

I’d love to hear your thoughts?

This article collates some good answers to resistive arguments for using Object Relational Mappers.