Archive for February 2010

The build process

  • Ensure Binary Integrity of your build:
    • The build either works or it does not work. This way it is easier to rule out errors in different layers of the project like database or logic
  • Builds are obtained from files under source control:
    • This means that if a problem happens the error can be linked to a specific commit or tag under version control
  • Build can happen remotely (production) or locally:
    • This allows for the same local configuration to be tested on different environments remotely (production)
    • It can also allow specific special configuration (ex: a tag under version control) to be propagated to production
    • Basically helps prevent configuration errors by removing as much as possible the human aspect
  • All builds should contain a database script (under version control) that creates/restores the databaseĀ  from scratch
    • This way each database change is linked to a version under version control and errors can be linked to each build
    • Also this makes finding bugs a lot easier as they are easier to reproduce

Unitiy IOC

Basically, with Unity, I ended up writing something like this (simplified version) :

IUnityContainer container = new UnityContainer();

container.RegisterType<IRiskRepository, RiskRepository>();

string conn = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;

container.Configure<InjectedMembers>().ConfigureInjectionFor<RiskRepository>(new InjectionConstructor(conn));

UnityControllerFactory factory = new UnityControllerFactory(container);

ControllerBuilder.Current.SetControllerFactory(factory);

Unity turned out to work very well. I was able to save a lot of lines of code and it is greatly improving the testability of the dynamic modules I am using on the mock project architecture. Also, it was easy to set up. Its a good alternative to the other more popular IOC.

Namespaces be gone

If you do not need specific namespaces, remove them. Most of the time it is not a big deal in small projects but specially on ASP.NET websites projects it can make a difference. The main difference is thatĀ  the compilation time can be significantly reduced and it will speed up your IDE.

If the website contains a lot of namespaces and if the project has C# 3.0 + which enables the use of extension methods it can make a significant difference. By having a lot of namespaces and using extension methods it can make the autocomplete list huge!

One last thing to note that you wont see any particular speed up on the actual execution time of the project if you remove them, they will not affect performance at all once the application is compiled. Its just one of those practices that makes development a bit faster and nicer specially in old computers like the ones I use at work.

Inversion of Control

If you are building an application that has a lot of modules and those modules can be plugged in dynamically then you will probably want to use inversion of control (IoC).

What can inversion of control do for you?

  • help you deal with the configuration of all the modules
  • a one “single point change” so you wont have to hunt down every other place where things could go wrong
  • help with transparency as you just have to use a module and not worry how it is implemented
  • provide a nice way to have strong contracts (due to interfaces)
  • finally, the application can change it’s own behavior when it believes it is necessary at runtime

If you want to learn more I would recommend reading the the famous article written by Martin Fowler.