It’s been more than a year since I last actively participated as a developer in a development team. Sure, I wrote some kick-ass T-SQL scripts and the occasional line of C#. But, over the last year my tasks were more targeted to data modeling, functional design and project- and team coordination rather than to writing source code.
This was up until about 3 weeks ago, when I was given the chance to write some code again. I wrote most of the functional design for the project and a team of 3 developers already implemented a great deal of it.
Now, during the time of my source code writing abstinence, my colleague Davy Brion had done serving his time in Enterprise Hell and was asked to strengthen our in-house software development team. Davy introduced a lot of technologies and patterns that extended the way we previously developed our software projects.
He ditched our code generated data layer and introduced NHibernate instead. Being a big fan of dependency injection he also threw Castle Windsor into the picture. And to top it of, for our unit tests he showed us how to easily mock dependencies using Rhino.Mocks.
It only took me about a day or 2 to fully understand and start using the new architecture in a productive way. So how did I manage to grasp these concepts so quickly? Well, the answer is easy: they aren’t all that hard to understand!
NHibernate
While having had no experience in NHibernate at all, I already knew the general idea of ORM. And as I joined the development in a stage of the project in which already alot of funtionalities were implemented, I had some real life examples of mapping files, entities and data repositories laid out in front of me. Taking it from there was not that hard. Although for the occasional question it is kinda handy to have an NHibernate developer in your team.
Castle Windsor
Again, I knew about dependency injection as a way to implement strategies and the likes but seeing CW in action really blew my mind. You just register your components in code (or xml) and don’t care about them anymore. The IoC will automatically inject the configured dependencies for you (as long as you provide the means to do so by adding the corresponding constructor parameters or public properties).
Rhino.Mocks
We already were writing unit tests for a few years (as is the core of our genesis development methodology) before Davy introduced Rhino.Mocks. Some of the techniques a mocking framework solves were not new to me. I already had stubbed some dependencies with manually written ‘test’ code. Again, the simplicity of creating mocks, stubs and expectations with Rhino.Mocks really impressed me. And the unit tests are _fast_!
So, All’s Well That Ends Well?
I did manage to screw one thing up though :) I wrote a piece of code that created a new entity in memory and that did not initialize a non-nullable field. Since the tests for that code, mocked the data repository that is responsible for persisting the entity, they ran just fine while in fact they covered faulty code. Adding an extra test for every non-nullable field would solve this problem, but I don’t believe that is the best approach (a bit tedious don’t you think?). We’re already thinking about an elegant solution for this… maybe one day you’ll read about that on Davy’s blog orso… :)