Castle Windsor

Earlier today I managed to get sample code working that integrated Castle Windsor with ASP.NET MVC.  By creating a custom controller factory, I was able to delegate to Windsor to create the controller.  A side benefit of the custom factory is that there is no more “magic” that converts a call to “service” to the class “serviceController”.  Hopefully I’ll have some time to go further down this path to see if it really ends up helping some of our dependency issues, or if I’m just adding more problem points.  I expect the tough issue will be deciding which classes should go through Windsor and which should stay as they are.

Either way, I’m going to also give it a shot on my home RssReader project.  Since that’s in it’s early stages, should be interesting to see it evolve with Windsor integrated from the get go.

Project References

This issue keeps popping up in our environment, so figure I’d put out this quick tidbit:

When adding references to libraries that exist within the solution, you should make sure you add the reference via the Project tab, not the Browse tab.  This means you will have to have the target project loaded in the solution to add the reference.

If you don’t do this, command line builds will still be ok, but builds within the IDE can get all messed up due the the build order not being what it should be.  In general, you will get error messages indicating TypeA can not be converted to TypeA, which doesn’t make any sense.  What’s really happening is TypeA in the dll can not be converted to TypeA in the currently loaded project.

Once you fix the references, all should be good again.

Mocks

So, I’ve been tapped to do a presentation at work on using mocks for unit testing. Not a big deal really, I introduced some examples of using Rhino Mocks to do unit tests on our data layer code over a year ago. This led to a some interesting patterns in our code structure, combining command and template patterns, resulting in a single class for each query/save operation. Overall, I was very happy how it all turned out.

Now our focus is on testing the business layer. That also turned out to not be so bad since the business service allowed for some dependency injection.

But as I start getting closer to the presentation layer, things aren’t behaving so well. So I’m looking at refactoring in different ways:

1. Create test versions of classes that inherit the object under test. Let the test version override factory methods and have them return doubles/fakes/mocks at test time. My main concern is that the virtual methods will get abused in production code.

2. Create a more structured service locater factory, let it’s methods default to returning the types you’d expect in production, but allow other types to be registered for unit tests. Worried about issues with constructors/initialization logic here.

3. Use an Inversion of Control (IoC) container such as Windsor to manage dependencies. I haven’t played with this at all yet, but my gut feel is that we have way too many objects to define in a config file. Also worried about constructor/initialization logic. Obviously, I need to play with this to get a better feel for things.

In the end, I’m sure all of these are valid options, and will just have to see which tool to use in each situation.

I’ll try to get some samples written up soon to clarify the different options I’m considering

Back again

Giving the old blog another try. Intent here will be to mostly discuss software development topics, but I’m sure other stuff will creep in from time to time.