Stefan Moser's Blog

Boodhoo Voodoo

noreply@blogger.com (Stefan Moser) — Thu, 01 Dec 2011 04:14:00 +0000

Last week I had the absolutely pleasure of attending JP Boodhoo’s Develop With Passion Bootcamp at my company’s office in Regina.

The title of the course has recently changed from Nothing But .NET because it was misleading, and JP stated so several times during the week. While we learned a lot about .NET, design patterns and test-driven development, the real goal of the course is to teach developers the skills for learning on their own and opening their minds to alternative programming methods. So many developers rarely look outside of their own little circle of development for new ideas. It’s comfortable in their circles and looking elsewhere is something foreign to them. JP teaches the skills required to make those leaps outside of your comfort zone and be able to continually expand the boundaries of your skillset.

For some courses it is viable to send one person and have him bring back his learnings to the team. This is not one of those course. It has to be experienced first-hand. JP is extremely passionate about development and that passion is infectious. His ability to inspire developers and make people want to become better programmers is second to none. The course is carefully designed to guide each developer through a personal journey that cannot be replicated by someone else. JP has a special talent for inspiring people to strive to be better developers, and coupled with his ability to teach the skills to continue learning is a unique combination that has to be experienced in person.

This is definitely a course where you get out of it what you put into it. JP really challenges you and forces you outside of your comfort zone. I can say with certainty that every single person in attendance was quickly forced out of the comfort zone that they were used to being in when coding. What happened next was up to the individual. Those who chose to embrace that awkward feeling and challenged themselves to learn something new got full value out of the course. They learned a lot about patterns and different coding techniques and, more importantly, learned the skills required to keep the momentum of learning going. They not only became better developers in that week, they have set themselves up for continuing that rapid growth for a long time to come. However, those who chose to fight the discomfort and actively tried to get back into their developer rut, likely didn’t learn much and won’t have a very positive reflection on the course.

I highly recommend this course for developers of all levels. There is nothing more valuable in a developer than an active engagement and desire to continually improve their skills. I have been involved in the developer community for over 10 years and I know several other people who have taken this course. They couldn’t say enough good things about it and used the skills they learned to launch their careers to new heights. Having now taken the course myself, I can honestly say that this course is a great way to propel your skills to the next level.

The Report of ALT.NET’s Death Was an Exaggeration

noreply@blogger.com (Stefan Moser) — Tue, 10 May 2011 05:00:00 +0000

I spent last weekend in Redmond at ALT.NET Seattle 2011 and it was an amazing experience. This is the 3rd ALT.NET conference that I’ve attended and they’ve all been unique experiences.

A New Breed

There were very few of the original ALT.NET leaders at the conference, but it was awesome to see so many new people picking up the torch. There was a significant change in the atmosphere from previous ALT.NET conferences too. The theme of the conference was “practice don’t preach” and it was reflected in the attendees and conversations. I had so many great conversations with people based on their experiences and practices that they actually use.

James Shore gave an excellent keynote speech about cargo cults and how it’s important to understand the substance of an idea. This concept was solidified for me in a session about CQRS, which many believe is a cargo cult, but it was the most pragmatic conversation about CQRS that I’ve ever had. There was as much talk about when not to use it as there was about its benefits. All of the proponents of CQRS warned about the pitfalls and downside to it and provided a lot of experience based expertise. I didn’t hear a lot of talks with this kind of tone at previous ALT.NET conferences and it really struck me how the community has evolved.

Not Satisfied

One of the most thought provoking sessions happened near the end of the second day where a great discussion about learning occurred. If this conversation would have occurred at the first ALT.NET conference that I attended, it would have focused on TDD, Agile and pair programming. This time around those topics are accepted and we talked about pushing those techniques even further and incorporating organization learning techniques. It’s great to see how those early topics have been accepted and new ideas can be discussed to raise the bar even higher.

I had so many conversations with people who didn’t care about buzzwords and rhetoric and just wanted to find better ways to develop software. It wasn’t about who the big names were, just about sharing ideas.

ALT.NET Lives On

ALT.NET isn’t dead, not by a long shot. Just because most of the original ALT.NET leaders have moved on, a new generation of ALT.NETers have picked up the torch and are running with it. It may not be as in-your-face as it used to be, but those involved in the community are still pushing the .NET community as a whole forward. The ALT.NET community has evolved and it continues to provide a huge amount of value to the .NET community as a whole. It was a fantastic experience and I can’t wait to apply all of the new things that I learned.

Software Developer Résumé Tips

noreply@blogger.com (Stefan Moser) — Wed, 02 Mar 2011 00:27:00 +0000

I’m currently in a situation where I’m part of a hiring team for two different companies. I’ve been up to my eyeballs in developers’ résumés and I have to say that I’ve been less than impressed. The problem is that very few developers put anything in their résumé that distinguishes themselves from others. For the most part I’ve seen long lists of tools and technologies used, lists of places the applicant has worked along with more lists of tools and technologies they’ve used, and a short list of their education. None of this makes the applicant stand out as a developer.

Here are some tips that will help your résumé stand out and will get you to the next stage in the hiring process.

Passion

Tell me that you actually like doing what you do. Tell me about the books that you’ve read, the user groups you attend, the blogs that you read and the podcasts you listen to. It’s even better is you can link to your own blog and the open source projects you work on. Tell me why these things are important to you and how they help make you a better developer. I need to know that you’re not just coasting through your career and that you’re constantly trying to improve your skill set. I guarantee you that the job you’re applying for is not exactly the same as the one you have and I need to know that you will be able to adapt and thrive in a new environment. I want to know that you bring fresh ideas to the team and will help the team take advantage of changing technologies.

Champion Change

Tell me about how you’ve driven change in your development team to make it more productive, raised the quality of the code or reduced the bug count. Tell me about a pain that your team had and what you did to fix it. I want to know that you care about your team and that you care about the products your team produces. I need to know that you will be an asset to the team and will take action when you see a need.

Stand Out

Remember that you’re certainly not the only qualified candidate applying for the position and you must make your résumé stand out. Think about what’s on your résumé and how unique it makes you look. Ask yourself if it highlights what makes you the best candidate for the position.

Work Experience

Yes, work experience is important. The problem is that I’m learning way more about the companies you’ve worked for than I’m learning about you! Don’t just give me your company’s elevator pitch, your job description and a list of tools. Tell me about a valuable skill that you learned. Tell me something outstanding that you did to make the project succeed. Tell me how this experience has made you a better developer and how you will be able to apply those skills at your new job.

Think about what makes you stand out as a developer and ask yourself if that is reflected in your résumé. Make sure that your strongest assets are highlighted and will stand out to the person reading it. If you follow this advice you will have a much greater chance of moving to the next stage in the hiring process.

ADO.NET Query Causes SQL Server to Ignore Primary Key Index

noreply@blogger.com (Stefan Moser) — Thu, 24 Feb 2011 22:27:00 +0000

*Disclaimer* I am not a DBA. I'm just a poor, humble developer. I just happened to be the guy standing closest to the server when the DBA quit.¹

The Story

I came across a performance bottleneck today that had me stumped for a while. A query to the database, for a single record, by the primary key, was taking 3 seconds. Let me say that again, by the primary key, for a single record, taking 3 seconds. How could this possibly be? I pulled the query out into Management Studio and ran the query again after turning on the option to display the actual query plan. (Query –> Include Actual Execution Plan) I was quite surprised when the query plan was not using the primary key index at all. To make a long story short, SQL Server didn’t use the primary key index because the generated query supplied the parameters as NVarChar while the actual columns were VarChars.

The Cause

The query was generated by an open source tool, so I was able to dig in to find out how it crafted the query. Basically it came down to this code:

IDbDataParameter parameter = command.CreateParameter();
parameter.ParameterName = paramPrefix + name;
parameter.Value = val ?? DBNull.Value;
command.Parameters.Add(parameter);

This is pretty standard code for ADO.NET but the key isn’t in what’s there, it’s in what is not there. The parameter’s type is not specific which causes the .NET framework to use it’s own mapping of .NET type to SQL Server type. The value that was being passed into this piece of code was a string and automatically got mapped as an NVarChar, or System.Data.DbType.String.

The Solution

To get around this default I needed to use my own mapping to use the non-unicode string type.

parameter.DbType = DbType.AnsiString;

With this additional line of code, this query executed infinitely faster; I’m not kidding. It went from taking around 3 seconds and now consistently measures at 0 milliseconds. How often can you claim an infinite performance optimization in your system?

¹ This story is not true. It's a lie, made up. There’s has never been a DBA here, and if there had been, I would not have set foot anywhere near the server just to avoid such a situation. However, in many cases I am the Accidental DBA and I find myself struggling through problems just like this one.

Messing around with C# dynamic

noreply@blogger.com (Stefan Moser) — Thu, 27 Jan 2011 17:27:00 +0000

At last night’s ALT.NET Vancouver meet up we were talking about the dynamic keyword in C# 4.0 and how it could be used for dispatching a message to the appropriate message handler. The conversation with a look at Chris Nicola’s blog post on the topic.

The first test that he shows in the post fails.

[Test]
public void cant_pass_base_class_to_function_dynamically()
{
    dynamic handler = new FooMessageHandler();
    IMessage message = new FooMessage();
    handler.Handle(message);
}

To me, this was expected. Despite using the dynamic keyword for the message handler, the C# compiler is still going to use the same algorithm for method matching as it does on a static object. To make this method pass we need to add our own method matching, and in C# dynamic, that means overriding the TryInvokeMember method.

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
    result = null;

    if (binder.Name == "Handle" && args.Length == 1 && args[0].GetType() == typeof(FooMessage))
    {
        Handle((FooMessage) args[0]);
        return true;
    }

    return false;
}

This code looks to see if the Handle method was being called and then checks if the argument passed in will satisfy the real method then calls then method. It's not the cleanest code, but the test does pass with this override. We can take it a little further and move the method to the base class so that we don't have to repeat the override for each message handler.

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
    result = null;

    if (binder.Name == "Handle" && args.Length == 1 && args[0].GetType() == typeof(T))
    {
        Handle((T)args[0]);
        return true;
    }

    return false;
}

One of the conclusions that we reached at the meet up was that dynamic is well suited to where reflection would have been used. I have done message dispatching with reflection in the past and I think I like this approach better once I clean up the code a little more.

P.S. Also check out Cliff Hammerschmidt’s post on Graft-on Visitor in C#.

Inversion of Control: It’s All About Decoupling

noreply@blogger.com (Stefan Moser) — Fri, 07 Jan 2011 23:30:00 +0000

I've been using Dependency Injection and Inversion of Control for a few years now and have always wondered why there is such resistance to the concept. I've heard the argument that it seems too complex and on a not-so-recent Dot Net Rocks episode, Richard Campbell was concerned that it would make debugging more difficult. To me, Dependency Injection and Inversion of Control are just fancy words for a technique designed to reduce the coupling in your system.

Coupling is one of those terms that everyone knows, but few pay much attention to on a daily basis. I can remember an exam I wrote for a second year Computer Science course that had the following multiple choice question on it:

Object-oriented code should exhibit these characteristics:

a) High coupling, high cohesion
b) Low coupling, high cohesion
c) High coupling, low cohesion
d) Low coupling, low cohesion

I knew the answer right away, but thinking back on it, I couldn't have gone into much more detail about what those terms actually meant, or more importantly, how to apply the principles to code. I’ve found that coupling and cohesion are concepts that most people take a long time to apply at anything more than an elementary level.

At one place where I used to work, the development team completed 360 degree evaluations of the each other. One of the characteristics that we evaluated each other on was that we wrote “quality object-oriented code that displayed a low level of coupling and a high level of cohesion.” Vague I know, but what was most interesting about it was that the developers who wrote the poorest code in this regard scored themselves the highest, and the developers who wrote the best code, scored themselves the lowest. I interpreted this to mean that the developers who fully understood what it meant to write loosely coupled code were able to remove much of the coupling from their code, but were also keenly aware of the coupling that they left behind.

The argument that IoC makes debugging more difficult doesn’t hold any weight to me. The argument is that you don’t know exactly which implementation is being called when a method is called because the call is to an interface or an abstract class and not a concrete dependency. Now listen up people, cause I’m going to let you in on a little secret, THAT’S CALLED LOW COUPLING! You’re only coupled to the interface, not the implementation, that’s what object orientation is all about!

So the next time someone tries to argue against IoC because it’s too complicated, just remind them about the foundations of object-oriented programming.

Agile Vancouver 2010 Tutorial Materials

noreply@blogger.com (Stefan Moser) — Sat, 06 Nov 2010 19:27:00 +0000

As promised, here are the materials from the Domain Patterns Big & Small tutorial. Chris has posted his material on his blog.

Domain Patterns Big and Small.pptx

Samples (Before).zip

Samples (After).zip

Technical Debt, Non-Technical Managers and Tony Soprano

noreply@blogger.com (Stefan Moser) — Fri, 26 Mar 2010 19:29:00 +0000

Yesterday’s Ignite Your Coding webcast featured Dave Laribee speaking about technical debt. It was very insightful and Dave made several great points that make the technical debt metaphor more powerful. One point that struck a cord with me was that of “high-interest debt”. I’ve always found the technical debt to be a very powerful when talking with other developers, however, it seems to lose it’s effectiveness when talking with non-technical managers.

A Short Story

A few years ago I worked on a project that had a lot of technical debt, like mountains of debt. New development was painfully slow because of all the crappy code that we had to wade through just to make a simple change. The dev team had all sorts of inside jokes about it and any estimates that were given were always padded with a hefty “tax”. We all knew that we had loads of technical debt and had to do something about it, but the message always seemed to get lost when communicating this to management. Looking back now I can’t blame them at all because in their eyes, debt was how you grew the company. The company had been built with loans from angel investors and venture capitalists and this was considered a good thing, this is how the company was able to grow to the size it had in the short period of time that it had.

High-Interest Debt

What we as a development team failed to communicate was that the technical debt we had incurred was not the technical equivalent of loans from angel investors and venture capitalists. No, we had borrowed from Tony Soprano and every other loan shark in town, we’d maxed our the credit cards and had 3 mortgages on our homes. The fact is that in software, the interest rate on technical debt can run much higher than what business people are used to in the financial world.

Metaphors

This is the inherent danger of all metaphors, they only take the concept so far and end up implying meaning that was never intended. As business person already has preconceived notions about borrowing and debt that they will carry with them when speaking about this metaphor. From now on, I will make an effort to clarify the “interest rate” when speaking about technical debt to non-technical managers.

Paying Down Technical Debt

I would be remiss if I didn’t touch on strategies for paying down technical debt and the best resource I’ve seen is Dave’s article in MSDN magazine titled “Using Agile Techniques to Pay Back Technical Debt”. Go check it out so that you can start to pay down your debt and get Tony off your back so you won’t end up swimming with the fishes!

Speaking on Domain-Driven Design at .NET BC User Group

noreply@blogger.com (Stefan Moser) — Thu, 18 Mar 2010 19:10:00 +0000

I confirmed this week that I’ll be speaking at the .NET BC User Group in July. The title of my talk is “Domain-Driven Design: Redux” and it is a reflection of how I would have preferred to learn Domain-Driven Design if I got the chance to start again.

There is a scene in Good Will Hunting where Ben Affleck’s character, Chuck, is in a bar trying to pick up a girl. Another guy steps in a tries to show up Chuck by spouting his opinions on what he learned in an MIT class that Chuck said he had taken. Matt Damon’s character, Will, steps in to confront the other guy and lectures him that he only holds his current opinions because he hasn’t taken the follow up course yet, and when he does, he will predictably hold a different opinion. The point here is that Will has already taken the journey through the stages of learning and he recognizes the mistakes that the other guy is making, simply because he hasn’t progressed far enough in his thinking to understand the higher concepts.

This is a pattern that happens in Domain-Driven Design all the time, I went through it myself, and it sucks. When I first learned about DDD I was so caught up in the details of entities, value objects and services, that I lost sight of why I even cared about these patterns. I spent days trying to decide whether or not entities were allowed to call into services, I spent weeks searching for sample applications that modeled simple domains, I spent months figuring out how I could break the aggregate root pattern. These are all common stages that DDD newbies progress through, and they’re all pretty much irrelevant to DDD.

Domain-Driven Design newbies tend to focus on the details of the mechanics of DDD rather than focussing on the essence, “tackling complexity in the heart of software.” When we ignore the essence and focus on the mechanics, the mechanics feel very cumbersome and many people get frustrated by the complexity that they feel DDD has added, exactly the opposite effect that was desired.

This talk will emphasize the parts of Domain-Driven Design that I find are the most valuable. By focusing on these essential elements, the mechanics become more natural and have their intended effect of making complex logic more easily represented in code. If you’re interested in hearing more, please join us on July 7th 2010 at the BCIT Burnaby campus for a jam packed evening of all things DDD. More details here: http://www.netbc.ca/DNCal/EventDetail.aspx?date=2010/07/07

Judiciously Exposing Collections in the Domain

noreply@blogger.com (Stefan Moser) — Wed, 10 Mar 2010 17:53:00 +0000

This is a follow-up to Jimmy Bogard’s blog post found here: http://www.lostechies.com/blogs/jimmy_bogard/archive/2010/03/10/strengthening-your-domain-encapsulated-collections.aspx

Jimmy does a good job of explaining why exposing your collections as IList or IList<T> is likely not the best choice for your domain. His basic argument is that collections should only be exposed as immutable collections to client code.

Like Jimmy, I often expose collections as IEnumerable<T> but have run into problems with that too. While IList<T> with its 9 methods and 3 properties is exposing more than you want to, IEnumerable<T> often proves too limited with only its single GetEnumerator() method. I have found that creating custom collection classes has become an increasingly valuable method for showing intent.

Let’s take a very simple example, we want to expose a count of the orders that a customer has, and yes, I know there is a Count extension method on IEnumerable<T>, but bear with me, we’re starting simple here. Using Jimmy’s Customer/Order example, our classes would look like this:

public class Customer
{
    public OrderCollection Orders { get; private set; }
}

public class OrderCollection : IEnumerable<Order>
{
    private IList<Order> orders;

    public int Count
    {
        get { return orders.Count; }
    }

    public OrderCollection(IEnumerable<Order> orders)
    {
        this.orders = new List<Order>(orders);
    }

    public IEnumerator<Order> GetEnumerator()
    {
        return orders.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

Notice that you can still use the Orders property on Customer as an IEnumerable<Order> and we’ve also added a Count property. That was a very trivial example, so let’s look at something more interesting.

One of our requirements is to track the customer’s most recent order, so let's add this method to OrderCollection:

    public Order GetMostRecent()
    {
        return (
            from o in orders
            orderby o.OrderDate descending
            select o
            ).FirstOrDefault();
    }

We've added a method to our collection class that clearly states its intention. We haven’t over exposed other methods in order to achieve the requirement. We can test this method in isolation from the Customer class and we’ve encapsulated the logic and abstracted it away from other code.

There’s all sorts of methods that we could add to OrderCollection as required in our domain. We could add a method that returned all of the unshipped orders, or the delinquent orders. Whatever our domain requires, we have a place in our domain where the code belongs.

Collections within the domain are often over exposed and not well encapsulated. By creating simple custom collection classes we create intention revealing classes that don’t expose unwanted behaviour. They make the domain more discoverable, testable and encapsulated.

My Apps Are On The Topshelf!

noreply@blogger.com (Stefan Moser) — Mon, 26 Oct 2009 22:28:00 +0000

I stumbled across Topshelf the other day on Twitter (sorry, can’t remember who) and just deployed my first service using it. Topshelf is a bootstrapper for services that lets you run them as console apps or Windows Services without have to go through the hassle of actually creating a Windows Services. The best thing I can say about it is that it just works, no fuss. You can read this blog post for more information. Awesome job guys!

You can do what with an Auto Property?

noreply@blogger.com (Stefan Moser) — Thu, 01 Oct 2009 19:27:00 +0000

I hate auto properties. You know, these things:

public string UserName { get; set; }

That’s right, I can’t stand the fact that the language makes it so easy for me to break encapsulation on my objects. I find it insulting that .NET thinks I would rather save a few character strokes on the keyboard than actually follow the most basic of object-oriented principles.

Until now…

I have this property on an object:

public string UserName { get { return _userName; } }

I was a little curious today when I looked at my read-only property (because all of my properties are read-only) and I noticed that ReSharper had put a barely noticeable little green line under the first two letters of the property name. I’d seen this little green line before, but ignored it every time. I was a little curious what it thought I could to do make this code better, so I hovered my mouse over it and was a little surprised to see it suggest that I should convert it to an auto property. I mean, seriously ReSharper, there is no way that I’m going to convert that into an auto property because auto properties require a setter and setters are just plain evil! Ok, I get the irony in linking to that article since it says setters and getters are evil, but I’m willing to ignore that for now if you are.

Anyway, ReSharper thought I should use an auto property and I was steadfast against it, but I was curious. I’ve been using ReSharper for a few years and I accept nearly all of the suggestions it makes, but this one was getting the better of me. I was all ready to go on a big rant when I accepted the suggestion and ReSharper just went ahead and added the setter for me…but it didn’t…well…not really…at least not how I expected it to. This is what it did:

public string UserName { get; private set; }

A private setter! Why didn't I think of that?! Alright, you already knew that, this is no big deal to you, that’s OK. This is one of those little language features that, for whatever reason, I had never stumbled across before. It’s a small change, but I like it. I think I’ll accept that suggestion, thanks ReSharper.

Business Logic Patterns

noreply@blogger.com (Stefan Moser) — Fri, 18 Sep 2009 23:18:00 +0000

All of the patterns here are taken from Martin Fowler’s excellent book Patterns of Enterprise Application Architecture. The following is my interpretation of these patterns and the ramifications of each one. I highly recommend that you refer back to PoEAA for a full explanation of each pattern.

I presented a session on the first day of TechDays in Vancouver called “Layers: The Secret Language of Architects.” As part of that presentation we discussed some of the different patterns that are used for coding our business logic. After the session was over, several people commented that they particularly liked this part of the session and encouraged me to blog about it, so without further ado…

The Patterns

Transaction Script

Transaction script is the simplest of the three patterns. It is represented by simple procedural code that executes business logic with simple and straight forward programming constructs and does not use object oriented techniques.

Transaction Script should be used when the application has very simple business logic and is not expected to grow much beyond the initial development effort. It is very quick and easy to get going with Transaction Script because it does not require much in terms of supporting infrastructure. However, I strongly recommend that if you decided to use Transaction Script that you make explicit seams around it so that when (yes, when, not if) you decide that your application has outgrown the limits of the pattern it will only mean a rewrite of the business logic and not a rewrite of the entire application. As the complexity of the system grows, the Transaction Script breaks down quite fast. It causes a lot of duplication and often results in rigid and brittle systems.

Here is a sample of some Transaction Script code. I’ll be using the canonical example of a funds transfer where a given amount is transferred from one account to another. The logic is intentionally kept very simple so that it’s easier to talk about the different responsibilities being addressed in the code.

public class FundsTransferService
{
    public void TransferFunds(int fromAccountID, int toAccountID, decimal amount)
    {
        AccountDataAccess dataAccess = new AccountDataAccess();

        decimal fromAccountBalance = dataAccess.GetAccountBalance(fromAccountID);
        decimal toAccountBalance = dataAccess.GetAccountBalance(toAccountID);

        fromAccountBalance -= amount;
        toAccountBalance += amount;

        dataAccess.SetAccountBalance(fromAccountID, fromAccountBalance);
        dataAccess.SetAccountBalance(toAccountID, toAccountBalance);
    }
}

The code is very simple and straight forward. A data access class is used to retrieve the current balance from each account, perform the logic and then save the balances back to the data access class. Note that of the 7 lines of code in the sample, only 2 are actually business logic. The rest are infrastructure concerns.

Table Module

Table Module uses one instance to represent all of the rows in a database table. Each class wraps some representation of the database table (eg. a DataSet) and will pull out a single row to operate on a single item. The distinction of this pattern is that the business layer is written in an object oriented manner, but instead of storing the data in the objects, the data is stored in the DataSet.

Although DataSets were quite popular in the .NET world, very few architectures made use of the Table Module pattern. DataSets were usually passed around to represent state, but the object oriented representation of the business logic was not present. DataSets were instead used in Transaction Script patterns where classes were simply used to group related methods of procedural code. Table Module does scale in complexity better than Transaction Script because it can take advantage of object oriented techniques, but it still gets increasingly more difficult to implement new functionality because of the heavy infrastructure concerns that remain in the code.

Here is the same logic rewritten in the Table Module pattern.

public class FundsTransferService
{
    public void TransferFunds(int fromAccountID, int toAccountID, decimal amount)
    {
        Account account = Account.Load();
        account.TransferFunds(fromAccountID, toAccountID, amount);
        account.Save();
    }
}

public class Account
{
    private const string AccountTable = "Account";
    private const string IDColumn = "ID";
    private const string BalanceColumn = "Balance";

    private readonly DataSet dataSet;

    public static Account Load()
    {
        AccountDataAccess accountDataAccess = new AccountDataAccess();
        DataSet dataSet = accountDataAccess.GetAccountTable();
        return new Account(dataSet);
    }

    public Account(DataSet dataSet)
    {
        this.dataSet = dataSet;
    }

    public void TransferFunds(int fromAccountID, int toAccountID, decimal amount)
    {
        DataRow fromAccountRow = GetAccountRow(fromAccountID);
        DataRow toAccountRow = GetAccountRow(toAccountID);

        decimal fromAccountBalance = (decimal) fromAccountRow[BalanceColumn];
        decimal toAccountBalance = (decimal) toAccountRow[BalanceColumn];

        fromAccountBalance -= amount;
        toAccountBalance += amount;

        fromAccountRow[BalanceColumn] = fromAccountBalance;
        toAccountRow[BalanceColumn] = toAccountBalance;
    }

    private DataRow GetAccountRow(int accountID)
    {
        foreach (DataRow accountRow in dataSet.Tables[AccountTable].Rows)
        {
            if ((int) accountRow[IDColumn] == accountID)
            {
                return accountRow;
            }
        }
        return null;
    }

    public void Save()
    {
        dataSet.AcceptChanges();
    }
}

There is a lot more code in this example, but note how a subclass of Account could override the TransferFunds method if the business logic required specialized logic. The subclass could reuse all of the infrastructure code and just change the business logic.

Domain Model

Domain Model is an object model that encapsulates both the data and the behaviour. It takes full advantage of object oriented principles such as encapsulation and polymorphism. The Domain Model pattern is the best of the three patterns at representing complex domains. It is the power of isolating the domain from the infrastructure combined with the modeling power of object oriented languages that allows the complexity to scale well when using this pattern.

Business logic implemented with a Domain Model requires significant effort to isolate it from infrastructure concerns. Because of this additional effort it initially takes longer to develop systems using the Domain Model pattern. However, due to the powerful methods for representing business logic, it becomes relatively easier (compared to the other patterns that is) to develop as the system grows in complexity. An initial effort to set up the surrounding infrastructure is rewarded later on by allowing the developers to maintain a constant rhythm and speed of development.

Here is the funds transfer logic as represented using the Domain Model pattern.

public class FundsTransferService
{
    public void TransferFunds(Account fromAccount, Account toAccount, decimal amount)
    {
        fromAccount.Debit(amount);
        toAccount.Credit(amount);
    }
}

public class Account
{
    private decimal balance;

    public void Debit(decimal amount)
    {
        balance -= amount;
    }

    public void Credit(decimal amount)
    {
        balance += amount;
    }
}

Note the simplicity of this solution and that every single line of code is directly representing business logic. It is this isolation and focus on business logic that allows it to scale well with complexity. There is no persistence in this code sample, which is intentional, and persistence techniques will be discussed next.

Persistence in a Domain Model

In the TechDays presentation we presented Active Record and Domain Model as two separate patterns. This was a conscious diversion from Fowler’s patterns because this is the way that we have observed systems were being built in the wild, that and the fact that none of us had actually ever seen a system that used Table Module. The prevalence of Active Record tools and frameworks has caused it to be considered a different pattern than Domain Model. If you go by Fowler’s definition though, Active Record is a persistence pattern of a Domain Model.

Active Record

Active Record uses a one to one mapping between Domain Model classes and tables in the database. Each class is mapped to a table, each instance is mapped to a row, and each field is mapped to a cell. Classes are also responsible for loading and saving themselves to the database.

When using Active Record for persistence, we must add some more code to our Domain Model.

public class FundsTransferService
{
    public void TransferFunds(int fromAccountID, int toAccountID, decimal amount)
    {
        Account fromAccount = Account.Load(fromAccountID);
        Account toAccount = Account.Load(toAccountID);

        fromAccount.Debit(amount);
        toAccount.Credit(amount);

        fromAccount.Save();
        toAccount.Save();
    }
}

public class Account
{
    private decimal balance;

    public void Debit(decimal amount)
    {
        balance -= amount;
    }

    public void Credit(decimal amount)
    {
        balance += amount;
    }

    public static Account Load(int accountID)
    {
        // TODO: Implement this method
        throw new NotImplementedException();
    }

    public void Save()
    {
        // TODO: Implement this method
        throw new NotImplementedException();
    }
}

This technique combines the responsibility of persistence and business logic. Note that we have added some persistence code to business logic, so there is some mixing of concerns. There are several Active Record frameworks that will allow you to remove much of this code from the entities and let the framework handle it, but the concepts remain the same.

Object Relational Mapper

Object Relational Mapper is a pattern that puts a high value on Persistence Ignorance in the Domain Model. The Domain Model should know nothing about how, or even if, it is persisted to the database. An Object Relational Mapper is used to map between the Domain Model and the relational database. Unlike Active Record, the two models can be quite different and take advantage of the powers of each paradigm. In order to isolate the Domain Model from persistence knowledge, it is usually required to use a Service Facade layer to coordinate the usage of the Object Relational Mapper.

Let’s have a look at the added infrastructure required to use the Object Relational Mapper pattern.

public class FundsTransferFacade
{
    private readonly IAccountRepository accountRepository;
    private readonly IFundsTransferService fundsTransferService;

    public FundsTransferFacade(IAccountRepository accountRepository, IFundsTransferService fundsTransferService)
    {
        this.accountRepository = accountRepository;
        this.fundsTransferService = fundsTransferService;
    }

    public void TransferFunds(int fromAccountID, int toAccountID, decimal amount)
    {
        Account fromAccount = accountRepository.Get(fromAccountID);
        Account toAccount = accountRepository.Get(toAccountID);

        fundsTransferService.TransferFunds(fromAccount, toAccount, amount);
    }
}

Here we have added a Service Facade layer that handles the translation into the Domain Model "language". I am also assuming that an Object Relational Mapper is being used, and Aspect Oriented Programming to wrap calls to the Facade Layer which initiates and cleans up the ORM. This is write once code and is not worth showing here. This is the added infrastructure that is required to get going with a Domain Model, but once it is in place, we can focus more on the business logic.

Summary

We had a look at three difference patterns for representing business logic. We examined some code samples to illustrate how each pattern will handle increased complexity. Finally we looked at some of the infrastructure options that we need to implement when using the Domain Model pattern. I hope this was a valuable exercise, and if not, please leave a comment so that I can improve it.

TechDays 2009 Retrospective

noreply@blogger.com (Stefan Moser) — Wed, 16 Sep 2009 05:31:00 +0000

I’ve just arrived home after the end of TechDays Vancouver and I feel compelled to write a retrospective on my experience. I have to say that TechDays was nothing like I expected. I want to write this post with complete honesty to best tell the full story. I hope that this transparency is appreciated.

About 6 weeks ago there was a flurry of activity in the blog-o-sphere about the lack of fundamentals covered in TechDays sessions. I replied to this with my own comments as I felt at the time that, in conferences like TechDays, Microsoft was so intent on marketing that they would not allow any fundamentals sessions. This blog post got me in trouble because no more than a day later John Bristowe (Developer Evangelist for western Canada) contacted me to ask if I was interested in presenting at TechDays in Vancouver. I was a little hesitant at first, especially given my thinking at the time, but I decided to explore the opportunity and see where it went. John sent me a list possible sessions and one session jumped out at me right away. It was entitled “Test-Driven Development Techniques” but I didn’t really have a lot more to go on. This was a session that was originally presented at TechEd, so I was given the slides, demo and a video of the original presentation. I thought the session was alright, but decent enough that it delivered content that would be valuable to the community and did not focus on marketing a Microsoft production. I have since heard 2nd, 3rd, 4th hand accounts of how John and team had to fight to keep this and another session in TechDays because they did not market a Microsoft product enough.

A little while later Justice Gray contacted me with a very cryptic message, but hinting at the fact that there might be opportunity to present some content that was more centered around development foundations. I responded to him with my ideas, and sure enough, it was soon confirmed that Microsoft had agreed to add an additional Developer Foundations track to TechDays in Vancouver. I was quite excited about this opportunity because I had a pretty good idea that Justice and I were of similar mind and that this session would be quite aligned with my ideals about software development. Once the abstracts had been made available to me, I selected the session about the S.O.L.I.D. design principles, which I was quite excited about. I did feel quite under the gun given that TechDays was not far away and I had already agreed to present another session that I needed to prepare for. Given that I was already feeling swamped, not to mention I was in the middle of a home renovation, I asked Justice if I could give my input into the vision of the presentation, but ultimately I did not feel that I had the time to fully write it.

Over the next few weeks I was preparing madly, rewriting the demos and changing up the first couple slides for the TDD talk. I was collaborating with Justice about the content for the SOLID talk and still trying to find some time to drywall in the evenings. Once the planning for the Developer Foundations track started coming together, Justice and Peter Ritchie decided on the order of the sessions and it meant that my TDD and SOLID talks were back-to-back on the first day which I wasn’t comfortable with because I felt I would not be able to give either talk my full effort if they were so close. Given this conflict, it was decided that I switch talks in the Developer Foundations track on the first day and present the Layers session instead. It wasn’t supposed to be a big deal given that Adam Dymitruk was responsible for the content of the session. So now I had somehow gone from zero to three sessions in no less than the span of about 3 weeks and was wondering how the hell I had got myself into such a mess!

At this point in time my home renovation got put on hold. I told my wife that I was not allowed to complete the next step until after TechDays was over. I spent a lot of time preparing for all of the sessions and have since decided that it is at least as much work to prepare for a session that someone else writes as it is to prepare your own. The only difference is that you tend to get the content later if you don’t prepare the content yourself.

I arrived at the first day of TechDays with a little trepidation, this was after all my first time speaking at a conference of any size. I watched Adam present S.O.L.I.D. since I was going to present it the next day. My first session was my TDD talk in the Core Fundamentals and Best Practices track. Looking back on it now, I think I was so focused on the presentation that I barely noticed that there were over 200 people in the room watching me. I do feel that it went quite well and that people got the point of what I was trying to convey. I had an attendee come up to me after and comment on how expressive my test method names were. I used English readable sentences and he told me that he usually liked to try to keep his method names under 6 characters, but thought it was pretty cool to see some expressive method names. Now this was not a focus of the presentation at all, but if this is all that he takes home from the session then I think we have to count that as a win.

After lunch I presented on Layers and I think it went alright. Of the three presentations that I was presenting, I felt the least comfortable with its content. Reception to the talk was quite positive, so I’m fairly pleased with how it turned out. We weren’t quite sure what to expect in the Developer Foundations track given its late addition to the conference, but we were relatively pleased with the 30 or 40 people that were in attendance. We had roughly the same level of attendance for all four sessions in the track that day.

I arrived early on day two since I was presenting S.O.L.I.D. in the first time slot of the day. Justice and I were talking as we were setting up and wondering ifwe could realistically expect anyone to show up. All of the sessions in this track had been presented already the day before so we figured that attendance would have to be less than the previous day. Needless to say that we were both absolutely shocked when there were not only more people in attendance than the previous day, but the room was packed! Seriously! There were people standing in the back! I was quite excited about this talk since it was my favourite of the three I was doing, and I was really happy with how it went. After I finished, an attendee came up to me and told me that he had flown in from Calgary just to attend the Developer Foundations track. Think about that for a minute. TechDays is happening in Calgary in November, but he felt that the content of the Developer Foundations track was important enough to spend the extra money to fly to Vancouver just to attend this track. This absolutely floored me and is probably why I have felt the need to ramble on here for so long.

The rest of the day I spent relaxing and taking in the other speakers in the Developer Foundations track and the room was just as packed for each one of them. Something happened between the first and second day of TechDays. Something compelled a lot more people to attend this track the second day and I’m still at a loss to explain it. I’m hoping that when we get to read the evaluations that it will shed some light on this.

The whole experience was much more than I imagined! I will freely admit that there was about a 0% chance that I would have attended TechDays if I hadn’t had the opportunity to speak, so I am so glad that John and Justice took a chance on me. I do mean that they both took a chance on me because I knew both of them only by reputation and by their blogs, and I’m pretty sure they knew even less about me. I understand the risk that they both took putting their faith in me and I only hope that I met their expectations.

I want to publically thank John for putting together the Core Fundamentals and Best Practices track, which I have a sneaking suspicion had something to do with the low attendance in the Developer Foundations tracks on the first day. Whatever battles you had to fight to put this together were worth it.

I also want to publically thank Justice and Peter for putting together the Developer Foundations track on such short notice. I know that it far exceeded my expectations and I’m certain that it exceeded the expectations of everyone involved. The biggest thanks goes out to all of the attendees that chose to come to check out my sessions and other sessions in the Developer Foundations track! Microsoft has said that it was an experimental track and that, if the response was positive, that it would be continued in the future. All I can say is that I’m looking forward to this track next year!

Why I Love NUnit

noreply@blogger.com (Stefan Moser) — Sun, 06 Sep 2009 23:43:00 +0000

I have to admit that I very little experience with other unit testing frameworks. I’ve never felt the urge to switch because NUnit has served me so well over the years. NUnit is simple, effective and does not create additional friction. NUnit does take some flack for not having changed much over the years, but I think that is a strength because it hasn’t had to.

Recently I took the plunge into MSTest. I hadn’t heard many good reviews, but from the outside it looked “the same”. I mean, all I need to do is replace [TestFixture] with [TestClass] and [Test] with [TestMethod] and it would all work, right? Wrong. I was about to post “Why I Hate MSTest” but in the interest of staying positive, I’m posting “Why I Love NUnit” instead.

NUnit stays out of the way. It does not impose any structure on the project structure I choose. I can choose to put test classes in the same assembly as the classes they test, or I can choose to put test classes in a separate assembly.

Asserts just work. This is especially evident when comparing collections. I can compare collections of different types, it doesn’t matter if it is a Collection<T>, an IEnumerable<T> or an IList, NUnit is smart enough to compare each of the items in each collection. I had not even thought of this until I switched frameworks and it didn’t work.

When a test fails, NUnit tells me why the test failed with a very descriptive message. This is extremely important because I want to maintain the short cycle rhythm of TDD. Some frameworks rely more on providing links to the code that failed rather than providing a helpful message, but when running tests from the command line or with TestDriven.NET I can only rely on the error message.

TDD is a practice that strives to create a constant rhythm for the developer in order to maintain constant progress. NUnit is a framework that just stays out of the way and allows the developer to maintain that rhythm without fuss or interruption. Simple, concise, effective. What else would I want?

This Just In: Developers Value Passion And Fundamentals!

noreply@blogger.com (Stefan Moser) — Thu, 27 Aug 2009 18:44:00 +0000

I just received my MSDN Flash newsletter in my inbox and noticed the results of last week’s poll. The question was “what is the most important trait of a programmer fresh out of college” and I was pleasantly surprised by the results!

I would like to think that these are traits that are valued in programmers of all skill levels. One could also argue that if you combine the top two results, then programmers that have a passion for continuously learning about fundamentals are the most valued programmers of all! If you agree, then I have fantastic news for you because a new track has been added to TechDays in Vancouver and Toronto!

I will be presenting Test-Driven Development Techniques in the Developer Fundamentals track and I will also be presenting about…wait…ummm…something really cool and worthwhile in the newly announced Developer Foundations track. More info on that one when the MS legal department stamps their approval.

New Developer Foundations Track at TechDays Vancouver!

noreply@blogger.com (Stefan Moser) — Fri, 07 Aug 2009 17:52:00 +0000

It has been a crazy couple of weeks since my last post about the lack of fundamentals at TechDays. Shortly after, John Bristowe (Developer Evangelist for Western Canada) contacted me about presenting the TDD session at TechDays in Vancouver. After some back-and-forth, I decided that what better way to influence the material at TechDays than to present it myself, so I agreed and will be presenting.

In the meantime, we also announced the evening sessions presented by ALT.NET Vancouver. We’ll be hosting a keynote speaker and a series of lightning talks in the evening of Sept 14th, followed by an evening of open spaces on the evening of Sept 15th. This will be a great opportunity for you to bring up any topics that you would like to have covered that were missing from the main conference.

Also, earlier this week Justice Gray contacted me about what I thought was missing from TechDays and what sessions I would add if given the chance. This was right around the time that he was hinting that there might be something in the works, but I couldn’t have guessed that he had actually managed to get a new track added to TechDays Vancouver! That’s right, TechDays Vancouver (and Toronto) will now have a Developer Foundations track that will be expanded to all TechDays in the future if it is successful, and who is going to doubt that?

It’s awesome to see that Microsoft listened to the community and added this track. A big thank you goes out to the TechDays people, Justice and Peter Ritchie for making this happen!

Software Development Fundamentals at TechDays 2009

noreply@blogger.com (Stefan Moser) — Thu, 23 Jul 2009 16:44:00 +0000

A conversation on the lack of fundamentals being covered at TechDays has been going on in the blog-o-sphere. It started with Justice Gray expressing his concern, to which Joey Devilla replied, and then Peter Ritchie got in on the act too.

Fundamentals are sorely lacking in much of the Microsoft development community, and yes, it would be awesome if Microsoft embraced this and flooded TechDays with sessions about SOLID, TDD, design patterns and lots of other technology-agnostic goodness. I totally agree with Peter that this would ultimately be good for Microsoft’s bottom-line, but I just don’t see this happening anytime soon.

We’ve all seen the Microsoft demo where the presenter opens up a designer, drags a few things around, presses F5 and then proudly proclaims that “I did it all without writing a single line of code!” Come on people, we’re DEVELOPERS! Writing code is what we do! If it were really that easy then why did I bother going to university to get a Computer Science degree? Why do I read books and blog to keep learning? Why do I still think that development is really tough?

When we adhere to the fundamentals of software development we end up with higher quality code with a lower overall cost of ownership. But here’s the catch, fundamentals are hard! Microsoft is a platform/tools vendor and they have every right to market their products at events like TechDays, but none of those products will make me a better developer as much as a solid understanding of software development fundamentals will. If Microsoft continues to market their products without a healthy dose of software development fundamentals, the community needs to pick up the slack.

Let’s keep calling out Microsoft when they focus too much on the tools. Let’s keep writing blogs to promote what we believe is important. And let’s reach out to those attending TechDays with our own message. Will there be an opportunity for TechDays attendees in Vancouver to learn about SOLID and other fundamentals?

Dddddddddddddefinitely!!!

It just might not be during the hours of the TechDays event. Stay tuned for more…

ALT.NET Canada 2009

noreply@blogger.com (Stefan Moser) — Mon, 15 Jun 2009 19:52:00 +0000

Last weekend after DevTeach in Vancouver we had the ALT.NET Canada open spaces event. It was a good idea to have it right after DevTeach because that meant several speakers stuck around for an extra two days of good conversation.

This was my second ALT.NET open spaces event and both have had a heavy dose of Domain-Driven Design sessions. There was one very interesting session title “Non-Relational Databases” which was an awesome discussion about the practical uses of products like CouchDB, BigTable and db4o.

The last session of the event was convened by Greg Young in which he proposed making ALT.NET Canada into a formal entity with a mandate to promote ALT.NET principles and practices within the Canadian .NET development community. A discussion also got going about starting up an ALT.NET user group in Vancouver. More on those to come later.

It was an exhausting week with both DevTeach and ALT.NET Canada, but well worth the lack of sleep. Can’t wait to do it again soon!

DevTeach Vancouver 2009

noreply@blogger.com (Stefan Moser) — Mon, 15 Jun 2009 19:50:00 +0000

Last week I attended my second DevTeach and ALT.NET Canada conference and it got me fired up enough to finally start blogging. I first set up my blog account over a year ago and wrote three posts that I never ended up publishing. So now I am officially entering the blog-o-sphere and am excited to share my journey as a software developer.

DevTeach was awesome as usual, even though the economy took its toll and significantly reduced the number of attendees. On the up side, I did find that the sessions I enjoy the most are often the ones with only a dozen people in the room and the session turns into a big discussion rather than just a speaker talking at the front.

Greg Young’s “Unleash Your Domain” was one of those sessions. Even though it was the fourth time that I have seen this talk, I still enjoy the conversations that come up and hearing how Greg is fine tuning his technique.

Ayende’s “ORM += 2” session (basically advanced NHibernate) gave me tons of new ideas how I can get even more out of NHibernate. I had rolled my own natural IDs which I can now throw away and I love the idea on future queries. More on those features to come later. I have been using NHibernate for nearly 3 years and am still amazed at the power I can get out of it.

David Laribee’s “Behavior-Driven Development Installed” session has me back trying BDD style tests. I had previously abandoned them because they made the use of test doubles (mocks, stubs, etc) very cumbersome, but with the AAA syntax of RhinoMocks that problem has gone away. Also more to come on this later.

The DevTeach sessions are awesome, but the truly best part is that the speakers don’t just hang out in the speakers lounge with each other. I had several conversions about a whole range of topics over lunch, in the hall, or in the bar afterwards. This kind of accessibility is what sets DevTeach apart from most larger conferences. All in all it was a fantastic 3 days and I can’t wait until the next DevTeach.