Sunday, 6 September 2009

Coffee or Synergy

I had a plan. At the time it seemed like a good plan, but in retrospect I have decided that maybe it was misguided. In an earlier post I mentioned that a lot of the interesting tools in the .Net space originated in Java. Things like NHibernate and NUnit were significant over there but were also very highly regarded in .Net and were high on my list of stuff to learn. This led me to think that I should concentrate on just using tools that exist on both platforms so I might have a better chance at performing well were I ever to have to work on a Java project.

The thing is, I'm not likely to end up in such a situation, and whilst Java and C# syntax is obviously similar I think that I would have more issues to worry about than not knowing a framework that I may or may not be allowed to use. As I spend more time learning bits and bobs about some of these tools and best practices it has become obvious that there are synergies between certain products. Researching NHibernate shows that there is a strong relationship to the Castle project, even to the point that some of their binaries are included in the NHibernate distribution. I had been planning to use Spring.Net for my IoC needs, but this makes me feel that Windsor would be a better fit, and that is the one that I hear about most when IoC in .Net comes up. Not that Spring seems to be a bad offering, it has some NHibernate functionality of its own, but the Castle Project seems that little bit more tightly bound.

Equally I had been looking into using NAnt for builds, but MSBuild seems to be a perfectly good product that will be installed on any machine that I am developing on and will also be on colleagues machines so I'm not going to cause problems if I use it. The fact that NAnt needs to call MSBuild to get anything done is another point in MSBuild's favour.

This has led me to decide that as I don't have any current requirements to work in Java, I would be better off trying to learn about what seem to be considered to be the best tools for .Net when there is a clear winner, the tools that seem to work best together when there are obvious synergies, and pay attention to what seems to best fit my requirements, or has a good learning curve and plenty of documentation. If I ever need to switch to Java I can learn to use whatever tools I need to then, and if I am already familiar with IoC, TDD, ORMs etc. then picking up a new one shouldn't be too hard as the underlying skills will be similar.

The tools that I am currently looking at are:

  • MSBuild - For automated builds that can fire off unit tests and other fancy things on a regular basis.
  • NHibernate - Deals with the CRUD in my database.
  • NUnit / xUnit / MbUnit - For unit testing to make sure that I've not just gone and broken something with a minor change that I was sure had no chance of causing a problem. NUnit is the daddy, but the others seem to have their followings too, so I am open to checking them out. MSTest seems to be less well thought of right now but this may start to change come VS2010 so I'll re-evaluate things when that surfaces.
  • Moq / Rhino Mocks - A good mock framework is essential for any serious unit testing. These 2 seems to be the best, at least in the open source arena, with Moq edging it due to reports of it being simpler to get started.
  • NCover / Partcover - for giving code coverage analysis of my unit tests. The free version of NCover is getting old now and is reportedly having some problems with some .Net 3.5 code so Partcover may end up coming to its rescue. Again this is something that may also be addressed with newer versions of studio.
  • Castle Windsor - For its Inversion of Control tools (a concept that is currently blowing my head up when I try to read about it. Methinks I'm just going to have to dive in and do some to grasp it.) There may also be other parts of the Castle Project that get a look in later on.
  • CruiseControl.Net - If I decide to set up continuous integration route then this is the tool for me, but CI may not really be applicable for a 1-man development team so it is a low priority to get sorted out.

There may well be more to add to this as I get deeper down the rabbit hole.


No comments:

Post a Comment