The ViewDataDictionary that is passed to the HtmlHelper can be empty, or made to contain the data you want for your test.

public static HtmlHelper CreateHtmlHelper(ViewDataDictionary vd)
{
  var mockViewContext = new Mock<ViewContext>(
    new ControllerContext(
      new Mock<HttpContextBase>().Object,
      new RouteData(),
      new Mock<ControllerBase>().Object),
    new Mock<IView>().Object,
    vd,
    new TempDataDictionary());</p>

<p>var mockViewDataContainer = new Mock<IViewDataContainer>();
  mockViewDataContainer.Setup(v => v.ViewData)
    .Returns(vd);</p>

<p>return new HtmlHelper(mockViewContext.Object, 
    mockViewDataContainer.Object);
}

The problem is that a relational database is not suited for storing an object-oriented model. An object is almost always a non-scalar value, meaning that it won’t fit well in a table row. Hence, we have to create a schema suitable for persisting our objects to a set of tables. This schema will be different for each type of object we have, so it’s a rather tedious task, but it solves the problem.

As always, we developers tend to dislike repetitive tasks, so we try to simplify and automate the extra work involved with creating an ORM. This has led to various design patterns such as DAO, and in recent years a set of fully automated ORM tools such as Hibernate (Java), NHibernate (.NET), SQLAlchemy (Python), and Propel (PHP) have become very popular. These tools offer a highly transparent solution to the ORM problem, at the addition of a cost that varies heavily with the nature of the ORM problem. Still, their presence moves us closer and closer to a solution – we are creating an abstraction that fully encapsulates the difference between a relational database as our storage for persistent objects, and the objects themselves. Hopefully, we will soon be able to create an ORM that induces a linear or perhaps even constant cost on our solution, regardless of the nature of the problem we are trying to solve.

But wait. The real problem we are trying to solve is how to persist the state of our objects, remember? The database is indeed a store, and hence a candidate solution, but using it introduces an impedance mismatch, which is another problem we need to solve. It really is like trying to fit a square block in a round hole.

Let’s stop trying to solve the wrong problem of creating an ORM, and start finding a solution to our initial and real problem of persisting our objects. Recent innovations such as LINQ has taken us a step in the right direction by making persistence an integral part of the language, but we’re still a long way from automated persistence for our objects. I am certain, though, that moving focus away from the challenges of an ORM and on to the challenge of persistence in general will take us further.

Let’s do that.

(And I’m sorry for reusing Dijkstra’s already overused phrase.)

I decided to create a simple test to see how much of a performance hit LINQ is. The simple test I deviced finds the numbers in an array that are less than 10. The code is quoted below.

public void LinqTest()
{
    const int SIZE = 10000, RUNS = 1000;
    int[] ints = new int[SIZE];
    for (int i = 0; i < SIZE; i++)
        ints[i] = i;</p>

<pre><code>DateTime start = DateTime.Now;
for (int t = 0; t &lt; RUNS; ++t)
{
    int[] less = (from int i in ints
                     where i &lt; 10
                     select i).ToArray();
}
TimeSpan spent = DateTime.Now - start;
Trace.WriteLine(string.Format("LINQ: {0}, avg. {1}", 
    spent, new TimeSpan(spent.Ticks / RUNS)));

DateTime start2 = DateTime.Now;
for (int t = 0; t &lt; RUNS; ++t)
{
    var l = new List&lt;int&gt;();
    foreach (var i in ints)
        if (i &lt; 10)
            l.Add(i);
    int[] less2 = l.ToArray();
}

TimeSpan spent2 = DateTime.Now - start2;
Trace.WriteLine(string.Format("Loop: {0}, avg. {1}", 
    spent2, new TimeSpan(spent2.Ticks / RUNS)));
</code></pre>

<p>}

Initially, I assumed the performance impact would not be too large, since its equivalent is the straightforward imperative loop, which should not be too hard for a compiler to deduce given static typing and a single collection to iterate across. Or?

LINQ: 00:00:04.1052060, avg. 00:00:00.0041052
Loop: 00:00:00.0790965, avg. 00:00:00.0000790

As you can see, the performance impact is huge. LINQ performs 50 times worse than the traditional loop! This seems rather wild at first glance, but the explanation is this: The keywords introduced by LINQ are syntactic sugar for method invocations to a set of generic routines for iterating across collections and filtering through lambda expressions. Naturally, this will not perform as good as a traditional imperative loop, and less optimization is possible.

Having seen the performance impact, I am still of the view that LINQ is a great step towards a more declarative world for developers. Instead of saying “take these numbers, iterate over all of them, and insert them into this list if they are less then ten”, which is an informal description of a classical imperative loop, you can now say “from these numbers, give me those that are less than ten”. The difference may be subtle, but the latter is in my opinion far more declarative and easy to read.

This may very well be the next big thing, but it comes at a cost. So far, my advice is to create simple performance tests for the cases where you consider adopting LINQ, to spot possible pitfalls as early as possible.