Before I begin I have to say something about the context in which I used RoR. A new customer came to us and wanted a web based app for internal usage, it would be used by about 10 people. It should be accessible via Internet as the employees of said customer would work from home. I had a direct contact to the customer and deployed 3 to 4 times a week. Therefore, using RoR, even with next to no prior experience, wasn’t really a risk as the customer could always see my progress and had a more and more usable application from day 1.

The first problem was the IDE, I really love Visual Studio, at least with ReSharper and I think it was a logical choice to use JetBrains Rubymine. I don’t regret it, instead I’d advice every .Net developer that wants to try RoR to use Rubymine.

The second problem was the OS switch from Windows to Linux, I used Ubuntu 9.04 and later 9.10. I started with a VM and later switched to dual boot, please don’t make my mistake: NEVER install Linux before Windows. Windows 7 kills Ubuntus boot loader and as someone with next to no Linux experience it’s some trouble.

Linux is a pretty nice OS though, the GUIs (Gnome, KDE etc.) are pretty bad compared to Windows, so don’t expect too much, they are usable but don’t stand a chance against Windows 7. As I was used to do everything with a nice blinky blinky GUI, I tried to avoid the console, a terrible mistake. Linux’ console interface is powerful, easy to learn and (in general) way faster than doing it with the GUI. Before anyone asks, I don’t want to code without a full fledged IDE, so VI, VIM Nano etc. weren’t an option.

Back to topic or better let’s start with the topic

First, it’s important to realize that Ruby and Ruby on Rails are two distinct things, Ruby is a language and Ruby on Rails is framework written in Ruby. I didn’t read a book to learn either, instead I just started hacking away. Whenever I found a problem I asked mr. Google.

What I learned in the very beginning, if you don’t find a solution on google’s first page, you are trying to do it wrong. Rails is an opinionated framework, if you try to do something in a different way you are pretty much lost, but this is not a downside, it’s actually very good as you can say that there *is* THE way.

Asp.Net MVC is the complete opposite, you have plenty of choices like what data access to use etc. You won’t find a single solution for any given problem, instead you’ll get people that tell you NHibernate is the best, others say that pure Ado.Net is the best etc. But this too is not a downside, it’s just the opposite approach. RoRs pros in this area are ASPs contras and vice versa.

Rails is completely model driven and the model is database driven, Active Record is a core part of RoR. For guys that are new to the MVC pattern or have a pretty good understanding of how it should work but haven’t actually used it, Rails is really great as you’ll learn what MVC really means. ASP.Net, again, gives you the choice to do MVC or crappy VC with all stuff inside the controller.

The Rails ecosystem is really great, for almost any infrastructure concern there is a plugin waiting to be used. Be it background tasks, authentication you name it. Asp.Net has the .Net framework that might lack some comfort but is way more powerful.

I like and love C# but Ruby is so much more expressive and easier to learn or write. Even subtle things like writing do_stuff if condition_is_met?  instead of if (condition_is_met){ do_stuff(); } make a difference in terms of expressiveness.

The really disturbing thing are the background tasks. For active record and the configurations to work properly, it’s required to load the entire rails stack every time you want to execute a task. If those tasks are done every hour, it’s not a problem but if you want to do it every minute, it’s a significant overhead. It takes about 10 seconds for the rails stack to load, that’s 10 seconds of 100% CPU usage every minute for about 3 to 5 seconds of work. To get rid of this, I had to take a pretty hacky way, instead of running such a background task, I simply issue a web request to a specific url.

One thing you’ll notice is that Active Record is both, RoRs strength and weakness. For all but the simplest queries the performance is not acceptable once your db reaches a specific size and you have to fall back to raw sql. And if I may give you an advice, if possible use a copy of the production database for performance optimizing, nothing is more accurate and useful. Please note that I really love optimizing queries and that I have a pretty low tolerance before I start to work on a query (again).

Deployment with RoR used to be pretty hard, but that’s no longer the case. Just google Phusion Passenger and Capistrano. A single command (cap deploy) is enough and you’re done. It’ll take care of almost anything out of the box and is easily extendable.

Early next year, I’m going to work on a personal project with ASP.Net MVC (and Visual Studio <3) as I’d like to see how it feels after working with RoR.

If you can live without the edge Ruby / Rails stuff, I’d recommend you to use Enterprise Ruby. Less memory consumption. Easy to install. Stable.

To install it, just get the newest tarball (at the time of writing this, its this). Unpack it and run the installer. The installer will check if you have all the required libraries, if you don’t, just install them, it shoudln’t be more than three.

Usually, the defaults are just fine, if you leave them, it will install ruby in /opt/ruby-enterprise-xxx. When your done, you should symlink the following:

sudo cd /opt/ruby-enterprise-1.8.7-2009.10/bin
sudo ln ./ruby /usr/local/bin/ruby
sudo ln ./rails /usr/local/bin/rails
sudo ln ./rake /usr/local/bin/rake
sudo ln ./gem /usr/local/bin/gem

If you want passenger, you could run the passenger nginx/apache installer, a really nice way to deploy rails apps.

You’re done. Just one thing to remember, if you install gems that create an executeable like capistrano, javan-whenever, cucumber etc, you should symlink them as well, otherwise you’ll have to call them from /opt/ruby-enterprise-xxx/bin

One more nice thing, if you installed postgresql and libpq-dev it will automatically install the pg-gem. This works with mysql and sqlite as well.

Use Cases

If you need to access an object throughout the application, like settings, the singleton pattern could be considered.

If you have objects that are very expensive to create but are state less (it doesn’t matter if you use instance a, instance b or instance c), the singleton pattern can improve the performance.

How does it work

The singleton pattern limits the number of instances of a given type, usually, the number is limited to just one.

The classical singleton pattern forbids direct instantiation of the object. Instead, you have to call a static method to get the current instance.

Example (in C#)

public sealed class Settings
{
    private static readonly Settings _instance = new Settings();
    static Settings() { }
    private Settings() { }

    public static Settings Instance
    {
        get { return _instance; }
    }
}

Another Method

Many IoC-container have some kind of lifecycle and most of them have a lifecycle called singleton or similar.

Whenever the container is asked for a type with it’s lifecycle set to singleton, the container will try to find an existing instance of the requested type.

If no such instance exists, the container will create one and save it for all further requests.

If the type exists, the container will simply return the existing instance.

Drawbacks

Without an IoC container, you rely on the implementation of the singleton in regards to unit testing.

A singleton is basically nothing more than a global variable. Therefore, all negative aspects of global variables apply to a singleton.

Use cases

If you have a bunch of low level services and want to consume them together in the UI, the facade pattern can help with that.

If you have to talk to an ugly legacy application, the facade pattern can be used to built an anti corruption layer.

If the underlying services take many arguments but your applications only uses very few of them and uses default values for the rest, the facade pattern can be used to hide those useless arguments. Doing so can lead to simpler and more readable calling code.

How does it work?

The mechanic behind the facade pattern is very easy to understand.

Imagine you want to display customers and their orders, the data access might be splitted up into a customerDAO and a orderDAO.

Without the facade pattern, you’d have to call the customerDAO for all customers and afterwards the orderDAO to receive all orders for each customer.

The facade pattern would simply hide those two calls and make them internally, exposing just a single method GetCustomersWithOrders().

Example (in C#)

First, the very basic DAOs:

public class CustomerDAO
{
    public Customer[] GetAllCustomers()
    {
        // Db Access...
    }
}

public class OrderDAO
{
    public Order[] GetOrdersWithCustomerIn(
        params Guid[] customerIds)
    {
        // Db Access...
    }
}

The UI that consumes those two DAOs:

public class ClientWithoutFacade
{
    public void DisplayCustomersWithOrders()
    {
        var customers = new CustomerDAO()
            .GetAllCustomers();

        var orders = new OrderDAO()
            .GetOrdersWithCustomers(
                customers.Select(x => x.Id).ToArray()
             );

        var custWithOrders = new List<CustomerWithOrders>();

        foreach (var customer in customers)
        {
            var cwo = new CustomerWithOrders(customer);
            cwo.AddOrders(orders
                .Where(x => x.CustomerId == cwo.Id));
            custWithOrders.Add(cwo);
        }

        // Fancy UI binding....
    }
}

Now, the facade and the new UI client

public class Facade
{
    public CustomerWithOrder[] GetCustomersWithOrders()
    {
        var customers = new CustomerDAO()
            .GetAllCustomers();

        var orders = new OrderDAO()
            .GetOrdersWithCustomers(
                customers.Select(x => x.Id).ToArray()
             );

        var custWithOrders = new List<CustomerWithOrders>();

        foreach (var customer in customers)
        {
            var cwo = new CustomerWithOrders(customer);
            cwo.AddOrders(orders
                .Where(x => x.CustomerId == cwo.Id));
            custWithOrders.Add(cwo);
        }

        return custWithOrders.ToArray();
    }
}

public class ClientWithFacade
{
    public void DisplayCustomersWithOrders()
    {
        var customers = new Facade().GetCustomersWithOrders();
        // Fancy UI binding....
    }
}

• Configuration is done via xml.
• LinFu is used as proxy factory.
• MbUnit / Galio is used for testing, dlls are included.
• NHibernate 2.1 and all the required files are included.
• SQLite is included for both, 32bit 64bit.

For those who have a 64bit os, as long as you use the ReSharpers test runner, everything should work fine. If you want to use another test runner, Icarus for example, you’d have to reference System.Data.SQLite.DLL from lib/sqlite64.

If there is anything wrong, please leave a comment.

The archive is available here.

If you want to know more about extension methods, you should take a look at this

Action Extensions

I really like the generic Action, Action<T> but i don’t to check for null every single time I want to fire them:

public static class ActionExtensions
{
    public static void Fire(this Action action)
    {
        if (action != null)
        {
            action();
        }
    }

    public static void Fire<T>(this Action<T> action, T arg)
    {
        if (action != null)
        {
            action(arg);
        }
    }

    public static void Fire<T, T2>(this Action<T, T2> action,
        T arg1, T2 arg2)
    {
        if (action != null)
        {
            action(arg1, arg2);
        }
    }
}

The same can be done with Func<T, TResult>:

public static TResult Fire<TResult>(this Func<TResult> func)
{
    return func != null ? func() : default(TResult);
}

public static TResult Fire<TResult, T>(this Func<T, TResult> func, T arg)
{
    return func != null ? func(arg) : default(TResult);
}

DataRow/ IDataRecord Extensions

If you have to work with IDataReaders or DataRows, chances are high that some of your code looks like this:

public void DoSomething(DataTable table)
{
    foreach (DataRow row in table.Rows)
    {
        var customer = new Customer
        {
            Id = (Guid)row["Id"],
            FirstName = row["FirstName"] == DBNull.Value
                                      ? string.Empty
                                      : (string)row["FirstName"],
            CompanyName = row["CompanyName"] == DBNull.Value
                                      ? null
                                      : (string)row["CompanyName"]
        };
    }
}

public void DoOtherThings(Customer customer, DataRow row)
{
    row["Id"] = customer.Id;
    row["FirstName"] = customer.FirstName == null
                                    ? string.Empty
                                    : customer.FirstName;
    row["CompanyName"] = customer.CompanyName == null
                        || customer.CompanyName == string.Empty
                                    ? DBNull.Value
                                    : customer.CompanyName;
}

These extension methods will reduce the code duplication and make it a little more readable:

public static class DataRecordExtensions
{
    public static T GetValue<T>(this IDataRecord dataRecord, string column)
    {
        return GetValue<T>(dataRecord, column, true);
    }

    public static T GetValue<T>(this IDataRecord dataRecord, string column,
                                              bool nullString)
    {
        var value = dataRecord[column];

        if (value == DBNull.Value)
        {
            if (typeof(T) == typeof(string))
            {
                if (!nullString)
                {
                    return (T) (object) string.Empty;
                }
            }

            return default(T);
        }

        return (T)value;
    }

    public static T GetValue<T>(this DataRow row, string column)
    {
        return GetValue<T>(row, column, true);
    }

    public static T GetValue<T>(this DataRow row, string column,
                                              bool nullString)
    {
        var value = row[column];

        if (value == DBNull.Value)
        {
            if (typeof(T) == typeof(string))
            {
                if (!nullString)
                {
                    return (T)(object)string.Empty;
                }
            }

            return default(T);
        }

        return (T)value;
    }

    public static void SetValue<T>(this DataRow row, T value,
                                                 string column)
    {
        SetValue(row, value, column, false);
    }

    public static void SetValue<T>(this DataRow row, T value,
       string column, bool defaultDbNull)
    {
        object val = value;

        if (defaultDbNull)
        {
            if (ReferenceEquals(value, default(T)))
            {
                val = DBNull.Value;
            }
            else if (typeof(T) == typeof(string))
            {
                if ((string)(object)value == string.Empty)
                {
                    val = DBNull.Value;
                }
            }
        }
        else if(val == null)
        {
            if (typeof(T) == typeof(string))
            {
                val = string.Empty;
            }
            else
            {
                val = DBNull.Value;
            }
        }

        row[column] = val;
    }
}

The code above could now be written as:

public void DoSomeThing(DataTable table)
{
    foreach (DataRow row in table.Rows)
    {
        var customer = new Customer
        {
            Id = row.GetValue<Guid>("Id"),
            FirstName = row.GetValue<string>("FirstName"),
            CompanyName = row.GetValue<string>("CompanyName", true)
        };
    }
}

public void DoOtherThings(Customer customer, DataRow row)
{
    row.SetValue(customer.Id, "Id");
    row.SetValue(customer.FirstName, "FirstName");
    row.SetValue(customer.CompanyName, "CompanyName", true);
}

In order to find out what he knows, I thought it would be a good idea to go through the code of some tools.

We began with a tool that prints invoices. It has two Forms and no architecture at all. Although the code was a mess, he could easily tell how it worked.

After that, we looked at a tool that queried some data, applied some validation to it and if necessary corrected it. This tool used the command pattern for validation / correction and loaded those commands via reflection (about 50 in total). It was way harder for him to tell what was going on. He asked why anyone would do things this complicated and suggested to use a switch block instead.

The third tool was a little more complicated, the UI used the passive view pattern, persistence was dealt with by NHibernate, StructureMap wired it all up and a test suite covered most parts. I wrote it some time ago but could still easily navigate through it as it was well structured but he was totally overwhelmed and unable to say anything other than “it is too complicated”.

Using these good practices has advantages but these advantages are not free.

There are way more developers like my trainee that never heard about good practices and the like than those who heard about these practices let alone applying them. These developers usually just want to get the job done and mostly they do so, on time.

If you work in a very small IT department that only deals with in house stuff, should you use patterns, unit testing and other good practices or should you just do it “the good old way”?

If you do it “the good old way” maintenance costs increase, time to bug fix / feature are less predictable yet everyone should be able work with it.

If you use good practices, maintaining your applications either can’t be done by every “developer from the street” or requires high upfront learning effort. On the other side, after this initial learning phase is over, the maintenance costs should decrease and time to bug fix / feature should be more predictable.

Security:

You can set rights on the procedure level.

Yes, but you can also set the rights on view / table level.

Stored procedures are always immune to sql injection. 
Ad hoc queries are always vulnerable to sql injection.

Wrong.

Stored procedures that take strings as parameters and execute them as sql are open to sql injection.

Parameterized ad hoc queries prevent sql injection.

Performance / Execution Plan:

The execution plans for stored procedures are cached whereas ad hoc queries generate new plans each time they are executed.

Wrong.

If there is an execution plan that fits the query, it will  be used. The db doesn’t care if the query was an ad hoc query or a stored procedure.

Stored procedures are not pre compiled, they are compiled at runtime, just like any other query.

There is one thing to note though, if you change a parameter (not the value but for example nvarchar(9) instead of nvarchar(22)) a new plan will be generated.

Source: MSDN1, MSDN2, MSDN3, Blog

Centralization:

With stored procedures you “have it all in one place”

Wrong.

You don’t have it one place, it’s in your application as calling code and in your db as stored procedure. If the procedure changes and requires different parameters the calling code has to change too.

You can reuse stored procedures and only have to optimize them once

While that is true, you have to see the other side too. If multiple applications use a stored procedure you can’t easily change the procedure. You’d have to make sure that you didn’t break any of the other applications.

Optional Parameters:

If you use stored procedures for updates, you have to choose between efficient queries and maintenance.

If you want to go with efficient queries, you’d have to create stored procedures for every use case that changes something. If you have a customer table, the procedures might be ChangeCustomerAddress, ChangeCustomerBillingAddress, ChangeCustomerName etc.

If you favor easier maintenance, you’d just have one big update procedure that takes all values at once.

With Ad Hoc Queries you can have both. It’s easier to maintain and more efficient if you have a single method that builds a query that excludes all unnecessary columns.

Changes:

You can change a stored procedure without redeploying the application

That is partially true.

If you really have to change a query, you’ll likely have to change the application too.

Tuning is another story, you can tune a stored procedure without touching the application. On the other hand, you could also tune the query in isolation and change the query when the application has to be recompiled for other reasons.

For those who haven’t followed the discussion, it all began with the release of NHibernate 2.1.

Shortly thereafter, Patrick Smacchia made this post where he analyzed what had changed in NHibernates code base and measured its quality with NCover. He came to the conclusion that it must be a daily pain to maintain the code.

In reply to that, Ayende said that it is structured, although not by name spaces and the like (Patrick’s analyses made that assumption) but different. To underline that NHibernate is indeed maintainable, he pointed out that several new committers joined last year, that there were many new features while at the same time fewer issues.

Frans Bouma made a comment where he said that even a mess looks like something acceptable to those who work with it. This lead to Ayendes post to which I respond.

I have to say, I agree with Ayende. Rating how maintainable a code base is can only be done by those who actually maintain it.

If you have to deal with an application written in a language you don’t know, would you say it’s unmaintainable just because you’re not familiar with the language? Code bases are to some extent like that as many, especially larger ones, have their very own conventions and those conventions aren’t limited to naming conventions and the like but can span the structural or architectural level too.

The VB6 application I talked about in my refactoring series was very easy to learn as the only used pattern was copy and paste. You’d simply go in, copy what you need and paste it into its new place, everyone could do it, everyone did it. However, the result was an unmaintainable mess.

Therefore I’d say that although learning a code base is required to effectively maintain it, learning and maintaining it are two different metrics that should be looked at independently. The learning cost is a one time cost, fixing a bug or adding a feature isn’t.

Yet another story is ongoing learning, this has directly to do with maintainability as no one can remember every line of an entire code base that has a sufficient size.

If a code base is consistent with its conventions, no matter how strange they may first seem to outsiders, there shouldn’t be a problem as this ongoing learning cost will stay at a low level.

Please note that I’m not saying “that’s a convention” excuses everything. There has to be a structure and concepts have to be followed but this structure or these concepts don’t necessarily have to jump the outsider right in the eye as it is the case in the classical three tier architecture for example.

Very short: Dependency injection allows you to decouple your code and to make it more unit test friendly.

Another commonly used phrase for dependency injection (DI) is inversion of control (IoC).

What is a DI / IoC container?

A DI or IoC container is basically just a type map that returns a specific implementation for a requested type. To do so, it has to be told in some way what it should return if it is asked for a given type.

Most, if not all, DI Containers automatically resolve dependencies. You’ll find an example below.

The benefits are less code duplication, you specify a concrete implementation at most once and easier unit testing because you can test each component in isolation.

The only downside is the little upfront effort that is required to configure the container.

What is StructureMap?

StructureMap is a popular DI Container with a very easy to use api for both, normal use and configuration.

The mainly used method of StructureMap is in the static ObjectFactory, the methods signature is T GetInstance<T>(). This method is enough for most use cases.

StructureMaps configuration capabilities are also very interesting as they are powerful while easy to use.

You can get it and further information here.

A very basic example:

We have these interfaces:

public interface IA
{
    IB B { get;}
}
public interface IB
{
    IC C { get; }
}
public interface IC { }

With these implementations:

public class A : IA
{
    private readonly IB _b;

    public A(IB b)
    {
        _b = b;
    }

    public IB B
    {
        get { return _b; }
    }
}

public class B : IB
{
    private readonly IC _c;

    public B(IC c)
    {
        _c = c;
    }

    public IC C
    {
        get { return _c; }
    }
}

public class C : IC { }

Such a construct has a long and ugly instantiation, new A(new B(new C()))). Unit testing the class that makes this call is limited as it directly depends on A, B and C.

The other option would be to create B in A’s constructor and C in B’s but doing so would harm unit testing even more as testing A without B and B without C is impossible.

Before I show you how to configure StructureMap, you should know that StructureMap uses so called Registries for in-code configuration and that you’d normally configure it as early as possible.

In WinForms “as early as possible” might be before calling Application.Run. If you name the registry ClientRegistry, it could look like this:

public static void Main(params string[] args)
{
    ObjectFactory.Initialize(x => x.AddRegistry(new ClientRegistry());
    Application.Run(ObjectFactory.GetInstance<Form1>());
}

And here are two ClientRegistry implementations that would do the job for the above case:

public class ClientRegistry : Registry
{
    public ClientRegistry()
    {
        ForRequestedType<IA>()
            .TheDefaultIsConcreteType<A>();

        ForRequestedType<IB>()
            .TheDefaultIsConcreteType<B>();

        ForRequestedType<IC>()
            .TheDefaultIsConcreteType<C>();
    }
}

public ClientRegistry()
{
    Scan(x =>
             {
                 x.TheCallingAssembly();
                 x.WithDefaultConventions();
             });
}

Both would map IA to A, IB to B and IC to C, in implementation 1 it’s obvious but it looks like code duplication. In implementation 2 its not obvious at all, basically all it does is looking through all types in the calling assembly and to map those types that conform to the default conventions. The default convention is mapping interfaces to classes with the same name just without the leading I.

All you have to do now is call ObjectFactory.GetInstance<IA>(), in this case you’ll get an instance of A.