Chris Cyvas

For anyone that follows the forums pretty closely, you’ve probably run across my trials, tribulations, and lamentations about SubSonic. The crux of that whole issue is tight coupling. Most of us have heard that tight coupling == BAD, loose coupling == GOOD. Tru Dat! And to be fair, it’s not just SubSonic that is tightly coupled. All of dashCommerce is. I knew this when I designed it because I didn’t want the community to have to suffer my ego – meaning, I wanted to get a product out that was functional and useful – not something that shows off what I can do but fails in execution. In addition, I didn’t think the community was demanding any of the Developer Kung Fu that gets introduced when writing a loosely coupled application. To be sure, it introduces a lot of indirection, and if you don’t know where to look or if you aren’t familiar with things like Dependency Injection or Inversion of Control, then you are going to get confused – and fast.

Com’on Baby, loosen up . . .

dashCommerce is growing – and fast. My version of dashCommerce is different than the released version – I am pretty much constantly working on both versions – and that growth is resulting in something that is becoming more and more difficult to manage. The determination is that dashCommerce has finally grown to a point where the tight coupling is proving to be a hinderance to the ongoing development of the project. So we are going to be taking a crowbar to dashCommerce and prying apart all the bits, then we’ll put them all back together using some Dependency Injection.

Oh Please, not another DI fanboy!

I’m not. In 2005, when I was at Intuit, I was on the architecture team that was developing the next generation platform for the product – a large commercial business application (900+ db tables fully installed – freakin’ huge). Our charge was to come up with a platform / architecture that could serve the products for the next 10 years. In addition, we had some pretty amazing requirements. Customers could change the db schema, they could customize forms, reports, etc. We had row-level security, both licensed and hosted environments – you name it, we were charged with figuring it all out. In addition, customers could customize parts of the software, swap out providers, etc. Oh, and we had a consulting group that wanted to be able to drop in custom components. We were building the framework ontop of which all of our products would be built. It was a huge responsibility – the business was counting on us to execute. In our quest to figure this all out, I came upon Spring.NET and read about Dependency Injection. At the time, I thought: “All right, let’s see what all this is about.” Expecting to be completely underwhelmed, I set about creating a small sample application. It took about an hour to work it up – muddling through the docs and not really grokking what the end result would be (which results in a lot of second guessing) – but when I got it working, I was giddy. And the impact was immediately apparent. And so off we went with it. But I haven’t had occaission to use it since.

Unity can only be manifested by the Binary. Unity itself and the idea of Unity are already two. -Buddha

So, in looking over the selection of DI containers that have made their way into the .NET community, I knew I didn’t want to go with Spring.NET. Why? For no other reason than Spring.NET is an enormous application development platform and its HEAVY. That’s not a bad thing, but I don’t think it’s a good fit for an application that is going to be easing into and introducing DI. So Yitzchok and I started chatting about DI containers and which ones we wanted to look at using. Unfortunately, the decision was kind of made for us by our ongoing requirement to stay as Medium Trust compliant as possible. Asking folks to sacrifice security for our DI container choice wouldn’t pass the smell test IMHO. The only DI container that I found that expressly addresses Medium Trust in its documentation is Unity. So I played with it and it turns out that, so far, it’s working out nicely. It’s lightweight, it’s not trying to be more than what it is, and the API is friendly.

Programmtic Configuration vs. Configuration Files

There seems to be a trend in the .NET DI community to move away from configuration files and move toward programmatic configuration. IMHO, this is a mistake – you are sacrificing application flexibility for developer convenience. So, we will probably roll with configuration files, which makes sense to me, especially when considering our provider based model, and just as important, our budding vendor community. Being able to drop an assembly into the bin directory, changing a config file, and off you go – well that’s just precious.

So, if you aren’t sure about DI, or unsure as to what this means, grab Unity and work up a small sample. Do it with config files – it loses it’s impact if you do the configuration programtically – and let me know what you think.