We had a more complicated hql query that needed many joins, and included one join that didn’t involve primary keys. It ended up being pretty slow and the SQL generated was terrible, so I rewrote it into a custom SQL query. The model I needed mapped was an inherited table, so I’d somehow have to get NHibernate to map using data from both tables. There was a gotcha that took be a bit of time to get around. Here’s a kind of obfuscated version of the query.

var blocks = CurrentSession
.CreateSQLQuery("SELECT {stb.*}, {ev.*}, {ei.*}, {sm.*}, {v.*}, {p.*} " +
                "FROM TableA stb_1_ " +
                //Aliased funny because nhibernate doesn't map inherited tables automatically
                "JOIN TableB stb ON stb_1_.Id = stb.tbId " +
                "JOIN TableC ev ON ev.Id = stb_1_.evId " +
                "JOIN TableD ei ON ei.eiId = ev.Id " +
                "JOIN TableE sm ON sm.Id = ev.smId " +
                "JOIN TableF v ON v.Id = sm.vId " +
                "JOIN TableG p ON p.Id = ev.ppId " +
                "JOIN TableH zc ON zc.pc = v.pc " +
                "JOIN TableI mr ON mr.Id = zc.mrId " +
                "WHERE mr.Id = :mrId " +
                "AND stb_1_.ColumnA > 1 AND stb_1_.ColumnB > :now AND ev.DateTime <= :maxDate " +
                "AND stb_1_.ColumnC > 0 AND stb_1_.ColumnC <= 6 " +
                "AND (sm.ir = 1 AND ev.DateTime > :minDate OR sm.ir = 0 AND ev.DateTime > :minParamA) " +
                "AND (:rcId IS NULL OR :rcId IN (SELECT cId FROM TableJ WHERE pId = TableJ.Id)) " +
                "AND (:scId IS NULL OR :scId IN (SELECT cId FROM TableJ WHERE pId = TableJ.Id)) " +
                "AND (:pId IS NULL OR :pId = p.Id)")

.AddEntity("stb", typeof (TableB))
.AddJoin("ev", "stb.TableC")
.AddJoin("ei", "ev.TableD")
.AddJoin("sm", "ev.TableE")
.AddJoin("v", "sm.TableF")
.AddJoin("p", "ev.TableG")
.SetGuid("mrId", mrId)
.SetParameter("minDate", DateTime.UtcNow.AddDays(1))
.SetParameter("minParamA", DateTime.UtcNow.AddDays(5))
.SetParameter("maxDate", DateTime.UtcNow.AddDays(90))
.SetParameter("now", DateTime.UtcNow)
.SetParameter("rcId", rcId.HasValue ? rcId : (object) DBNull.Value, NHibernateUtil.Guid)
.SetParameter("scId", scId.HasValue ? scId : (object) DBNull.Value, NHibernateUtil.Guid)
.SetParameter("pId", pId.HasValue ? pId : (object) DBNull.Value, NHibernateUtil.Guid);

So I had to alias TableA as stb_1_ to get nhibernate to map that to my entity TableB. The reason is that NHibernate automatically generates aliases for the sources of your entity data. TableB fields mapped directly to stb, while fields that are a part of TableA were supposed to map to stb_1. If I left out the alias on that table, NHibernate would complain that it can’t map any of the fields because stb_1.FieldA (for however many fields you have) doesn’t exist. To get the alias I had to run the query without any aliasing and check the error message. It has a consistent naming convention, so it will continue working unless you change or add tables mapped to the entity.

Recently I was working on streamlining our unit tests by adding automocking for all the dependencies, rather than mocking each one manually with FakeItEasy. The problem I found is that we don’t have interfaces on all our dependencies, namely our service layer is all concrete classes that our web controllers reference directly. This causes a problem with automocking since the automocking (StructureMap automocker in our case) library won’t automock concrete classes, probably because it has no way of knowing if a concrete class is a dependency or not. I’ll probably end up hacking up the automocker code into pieces to get it going, but I think it probably would have been better to just bite the bullet and put interfaces on all of these classes even if we’d never swap them out. What would be even nicer is if .NET had some kind of syntactic sugar that would allow for the autogeneration of interfaces, kind of like empty properties.

Performance of NHiberate eager loading I was doing some profiling of a complex NHibernate query in our application and found it was doing a lot of N+1 stuff. What I found is that having mappings that would eager load references would cause an extra select for each result I returned. For example, we have a model called Performer, and it has this line in the mappings class (we use Fluent NHibernate):

References(x => x.ContentItem).Nullable().Not.LazyLoad().Cascade.None();

When I had a query that returned many performers, the profiler would show an extra select statement to get that content item. On the bright side, at least it’s executed all server side. This is the default behavior, but you can change it by setting the fetch type.

References(x => x.ContentItem).Nullable().Not.LazyLoad().Cascade.None().Fetch.Join();

Or you can lazy load everything by default, and join fetch in your queries when needed. Don’t join fetch against collection mappings though, otherwise you’ll get a cartesian product. I’d leave collection mappings as the default fetch-select for single results, and for multiple results I’d use a preload query that loads all the related items into the session cache so they can be lazyloaded without database calls.

Taking the plunge into the world of Node.JS after seeing a lot of buzz about it from startups like Scopely. The compelling thing to me is not so much the language (which is compelling coming from C#), but rather the style the developers of the platform are taking. Everything is very simple and clean, yet contains the powerful features I’m used to having in the .NET platform. The biggest change for me so far is the complete lack of any code intellisense. I understand that there’s no good way to get that in JS due to its prototype model, but I do miss it dearly. My first learning application is a simple web instant messaging platform using Express and Socket.IO. I’m calling it LameIM because it’s going to be lame.

So behavior-driven-development (BDD) has a lot of traction nowadays, and it certainly is a very useful way of designing specifications and translating them into tests. In many BDD frameworks, the style is to have a specification file and some code that tests that specification. Here’s an example from Specflow.NET: Scenario: Gutter game Given a new bowling game When all of my balls are landing in the gutter Then my total score should be 0 Specflow.NET will generate some code as such:

[Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute()]
[Microsoft.VisualStudio.TestTools.UnitTesting.DescriptionAttribute("Gutter game")]
[Microsoft.VisualStudio.TestTools.UnitTesting.TestPropertyAttribute("FeatureTitle", "Score Calculation")]
public virtual void GutterGame()
{
    TechTalk.SpecFlow.ScenarioInfo scenarioInfo =
    new TechTalk.SpecFlow.ScenarioInfo("Gutter game", ((string[])(null)));
    #line 6
    this.ScenarioSetup(scenarioInfo);
    #line 7
    testRunner.Given("a new bowling game");
    #line 8
    testRunner.When("all of my balls are landing in the gutter");
    #line 9
    testRunner.Then("my total score should be 0");
    #line hidden
    testRunner.CollectScenarioErrors();
}

Then you would have to implement a steps class that would contain the following functions:

[Given(@"a new bowling game")]
public void GivenANewBowlingGame()
{
    _game = new Game();
}

[Then(@"my total score should be (\d+)")]
public void ThenMyTotalScoreShouldBe(int score)
{
    Assert.AreEqual(score, _game.Score);
}

So you can see there is a very distinct boundary between the specification and the code that implements the test. MSpec is designed to make all this a lot more convenient by taking advantage of .NET features. Here’s an equivalent example in MSpec:

public class when_bowling_a_new_game
{
    static Game game;
    Establish context = () => game = new Game();
    Because of = () => { //Do Something };
    It should_give_me_score = () => game.Score.ShouldEqual(30);
}

The big difference is the amount of stuff that is required, because there is no disconnect between the spec and the implementation. This is great for developers since it removes a lot of repetitive code, but you’ll notice that mspec doesn’t allow parameters in the specs, so I had to put 30 in for the score assertion. Most likely because everything has to be compiled anyway and that wouldn’t make much of a difference from just changing the number and recompiling again.

MSpec is sort of a way for developers to write unit tests that flow more intuitively. However, I feel that if you’re going to use BDD, you might as well go all the way and use something like SpecFlow so business users can write their specs and developers can just translate them. You could use both as well, using MSpec as a replacement for something like NUnit, and Specflow for testing business rules. MSpec is certainly a lot more readable than the usual XUnit style.

We use Typemock at our organization for doing mocks in our tests. The reason is simple, like many other projects, there are deficiencies in the design (i.e. static classes) that traditional mock frameworks like Moq can’t handle. For those of you fortunate enough to be starting a new codebase, think hard about whether to use Typemock. Here are some pitfalls to Typemock:

1. It is slow. Just running tmockrunner alone on a test project will slow it down by upwards of 40%, even if you aren’t mocking anything. The runner is necessary because it is intercepting all of your method calls (and a bunch of other things I’m sure) and doing some voodoo to make this all work.
2. It can have really weird issues. I’m just speculating on why, but when you are mocking static classes, the cleanup and remocking of these classes can be inconsistent and you might get weird errors that you just can’t explain easily, or at all. Regardless, you will at some point end up pulling out your hair wondering why a test will fail when running in a batch, and succeed when running by itself.

Its greatest benefit is can also be its greatest weakness. You can mock just about anything you can possibly think of. Static classes? No problem. Swap out the next instantiation of a given type, also no problem. This allows you to carry on with possibly poor design decisions without any warning.

All in all, there’s obviously a huge market for Typemock, given that many projects aren’t all designed with full blown IoC and such, but still need to be tested effectively. Even those that are will still find certain edge cases where it would just be better to mock the static class, but those certainly should be the exception and not the rule. Consider placing all those tests in a separate project so tmockrunner is only needed there.

Fixed a fun unit test today. Apparently a year ago someone wrote a couple tests that checked for results that occurred within seven days from the current date. Normally it would return nothing as there were no rows during this time and there was an assertion to check that it was empty. The dummy data was either too far into the future or already past. However, one year from that day, which happened to be today, two rows happened to come into range of the seven day query, and the test mysteriously failed on our build server at exactly 12:30 PM.

The lead started looking into the build server logs, and found that the last checkin was only a configuration change, which was puzzling. Further down were frontend changes, also completely unrelated. I decided to debug the unit test and found that the query was pulling data that happened to be exactly seven days from today, causing it to fail. Lesson of the day, one year into the future isn’t far enough. Either that or make smarter tests.

I’ve seen far too often where software was either under or over-designed. I want to talk about over-design, since that seems to be more common in my experience. Over the past several years there have been many patterns discovered and naturally, developers often try to take advantage of them when they learn about it (I was no exception in the past). Unfortunately, these design decisions all have a price, usually in terms of maintenance or initial development cost.

For example, imagine the simplest web application, it might be a 1-tier design, and all the code is in a single project and it is not modular, etc. Costs of development are relatively low, but adding new features or changing things around would likely require significant rewrites. A developer nowadays might never think of using such a simple design, but that is a bit shortsighted, as we have to always consider the requirements. Maybe this is a one-off application that has a short lifespan of less than a year, then who really cares if it requires a rewrite to add a new set of features? Perhaps it is only 10k lines of code, why make a 3-tier design with IoC and all that jazz if it would only take a week or two to rewrite the whole thing from scratch?

On the other end of the spectrum there are applications like SAP, that have indefinite lifespans and are so insanely monstrous that they must be modular and well-engineered to adapt to change over time. The expensive design patterns prove their worth in these kinds of applications. If you have to measure the effort of a solution in man-years, the owner probably will want it to last for a while, so it makes sense to engineer it to do so.

When designing a solution to a problem, we should always consider the lifespan of the product and the maintenance requirements. If the application only takes a few people a few months to write it, it will probably take these same people a fraction of that time to rewrite the whole thing or a portion of it, and a rewrite will always produce a better product in the future than a code change. In cases like that, which seems very common in consulting, there isn’t any reason to build more than is absolutely necessary. Even if the product becomes outdated and needs a significant change every year, the costs would be pretty minimal to just brute force your way through it. That doesn’t mean developing a 1-tier system like I mentioned above, but don’t go overboard with all the fancy design patterns like SOA, IoC, WS, etc.

To use an analogy, imagine an architect (the traditional kind), who is designing a condominium complex. If it’s a high-rise, he would probably decide to put one or more elevators in the building, because people often need to go up and down the building and going up 20 flights of stairs is quite tiresome. And moving furniture up and down those same stairs would be unimaginable. So even though it will cost the tenants hundreds of dollars a month in fees to maintain the elevator(s), the costs are worth the benefits. Now imagine the same scenario in a 2-story complex. The tenants probably wouldn’t be happy paying such costs for an elevator when they’d be fine with using the stairs. Even if it would make moving furniture easier, it still probably would not be worth the cost to the tenants, since moving furniture doesn’t happen often enough and moving it up 1 story isn’t such a big deal anyway.

Software architecture isn’t quite the same of course, but every design decision has a cost (or lack thereof) and some kind of potential benefit. We must measure the costs and benefits as best as we can before making any decision. Don’t just throw patterns into your solution just because it sounds cool or it has a lot of buzz at the moment, it will likely end up being a waste of time now and in the future.