Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

Well, here we are again. Last time, we talked about project structure and came up with the one we’ll use for this series. Next we’ll talk tools. We’ll talk tools like Tim Taylor talks tools: with lots of grunts for my favorites and only a little explanation about what the tools do.) This is mostly because there is LOTS of material on the interwebs about all of these tools. I tend to favor the tools that are the most widely used for two main reasons: they have been battle tested by the largest crowd and two, they usually have the largest volume of content written about how to use them; some more useful than others. Having said that, let me also say that my choice of a specific tool doesn’t mean that the others in that space don’t have value. Most of the tools I will mention are all well respected by the well respected and each has its own strengths and weaknesses. If you are in charge of picking a developer stack, do your homework, but you could start with the stack I use and change fairly easily, if the particular tool doesn’t fit your needs. I will also easily swap one tool for another, if it will make the development process easier. ALT.NET… respect.

Getting on with it, there are several practices that I engage in on almost ALL projects that have tools that make them easier to do. The most important thing about a tool is that it should stay out of your way. Once you’ve set the tool in your stack it should grease the wheels of development. If it doesn’t, it’s either not the right tool, or you’re not using it correctly.

ORM or OR/M or O/RM (not sure where the slash goes)

An object-relational mapper is a tool that allow you to map your object model to your relational database (thanks again, Captain Obvious). Basically you tell your ORM that your Person object is stored in your People table and that it’s FirstName property maps to the FirstName field in that table and so on. Linq To SQL is an ORM. There are tons of them out there now. From free stuff (Subsonic, NHibernate and Castle ActiveRecord) to paid ones (LLBLGenPro and Telerik OpenAccess ORM come to mind). One of the things that will help in a transition to an ORM is adopting the idea that the relational database is merely a way to persist your object data. I have used only two and a half in the past: Nhibernate, netTiers and SubSonic. I say two and a half because I have not used SubSonic extensively or on a production project.. yet. It looks very promising. I choose NHibernate because of its many ways to map objects and it’s humongous user base. If I am hiring developers I can actually ask for NHibernate experience and probably see some.

IoC Container

IoC is inversion on control (so the C doesn’t stand for container and make for doubled-up words like GCO Carpet Outlet – Georgia Carpet Outlet Carpet Outlet). An IoC container helps to inject dependencies and works a bit like a factory method on steroids. If I have a dependency on a type, I can inject that dependency by inverting the control over that dependency to someone outside myself. If that made no sense, that’s ok, here’s how it works.

I need a laptop to make my presentation at the conference, but instead of lugging around my laptop (cause she’s a big girl), I can ask the conference to provide me with that laptop and bring only my presentation on a thumb drive. I am inverting the control of that dependency to the conference coordinators, and telling them it must have PowerPoint and Visual Studio 2008 on it. I “depend” on that contract. When I get there, I just ask for my lappy and plug my thumb drive in and away I go. This loosens the coupling to my machine. I don’t HAVE to have MY MACHNE to do the presentation. When I need a laptop for a talk, I just find one with PowerPoint and VS2008 and I get that dependency handed (injected) to me.

There are many free IoC Containers out there as well (StructureMap, NInject, Unity and Castle Windsor just to name a few). I chose StructureMap because of the large number of resources I found when doing research on Inversion of Control and Dependency Injection. (Also, Jeremy Miller is from Missouri, even if he lives in Texas now). I also feel very comfortable with the way you register you dependencies in StructureMap, although that could just be because that’s the tool I used to learn about Dependency Injection with.

BDD and the Infinite Melancholy

When driving a project, I try to drive it from the requirements (again, shaddap Captain Obvious). What I mean is, I try to codify those requirements so that they are executable. This makes them verifiable at every step of the project. Instead of “winging it” and hoping the change I just made doesn’t break something I developed yesterday or last week, I write the “specifications” in executable format, so I can use that as my checklist of what the system can do. I can also all the specs at any time to make sure everything still works as required by the customer.

For BDD, I choose Machine.Specification or MSpec. The syntax is very strange for C# developers at first, but I find the English-y way the code reads to be very compelling, and the report that it generates is a top-notch artifact to pass on to stakeholders. There are also other BDD frameworks out there (NBehave, NSpecify and you can even use RSpec (Ruby) to spec out your .Net code if you are so inclined.) Also, there are a few extensions to traditional unit-testing frameworks out there that allow you to work in a Behavio(u)r-Driven way (SpecUnit.NET, DevelopWithPassion.BDD and recently Gary Shutler has done a series on building your own BDD framework.)

Mock Me? Mock YOU, PAL!

If you’re going to do TDD/BDD, you’re going to need to mock. It’s that simple. If I tried to drive my design with BDD without using mocking or IoC, I would stab myself in the neck with a spork. Mocking is simply a technique of using “fakes” or “stand-ins” to isolate sections of your application in order to drive out their design. Remember, using BDD requires writing your spec first, THEN writing code to make it complete. By that very definition, you’ll be dependent on code that you haven’t developed yet and that you’re NOT going to develop yet. Mocking is the only way to get this done.

Again, there are free mocking solutions out there (Moq, NMock and RhinoMocks) and paid solutions (TypeMock). I’ve never used TypeMock, but I have heard that it can mock just about anything and if you’re trying to do TDD in SharePoint (I’ve heard) it’s the only way. I choose RhinoMocks, again because of the active user base and Oren Eini’s inability to stop coding/blogging/teaching for one second.

Architectural Pattern (MVSomething)

I started using a model-view-presenter pattern a couple of years ago, after I read an article from Jean-Paul Boodhoo in the MSDN Magazine in August of 2006 and a blog post from David Hayden about the Unity IoC container where he used Unity to wire together his Views and their presenters. It was an easy transition for me, because it felt a lot like web forms. At the time, ASP.NET MVC was in early preview releases and we had a significant investment in Telerik controls which (at the time) relied on ViewState to do some of their magic, and ASP.NET MVC doesn’t have ViewState available. I used MVP happily on several projects and still use it when a project requires ViewState or must be written in earlier version of ASP.NET.

ASP.NET MVC is the new kid on the block, but is making a huge impression. On me, as well. I have just begun to really dig into ASP.NET MVC, but the Sharp Architecture project can give some good guidance on how to set up, arrange and even test an MVC app. This is ultimately the one I have chosen for the project in this series, because it is very powerful and something I really want to get more familiar with.

Them Model-View-ViewModel pattern is the newest kid on the block and permeates the WPF stack (WPF Windows and Silverlight Apps). It is especially effective where two-way binding for your View to your View-Model is possible.

Quite a lot has already been written about all of these patterns, and rather than rehash them, I will just give links in the references area.

A-budee—A-budee—A-That’s all folks

I knew this was going to be a long post. We covered a lot of topics very lightly, but I felt it was important to give a short background on why and what we’ll use in this exemplary series. I’ll leave it at this for now, with some links below for more exploration. Then, next time, we’ll actually create the base project and set up it’s continuous build on our TeamCity CI Server!





Inversion of Control / Dependency Injection


Posted on Monday, September 14, 2009 10:00 PM | Back to top

Comments on this post: Let’s Build A Dev Shop (Part 5 In An Ngoing Saga)

# re: Let’s Build A Dev Shop (Part 5 In An Ngoing Saga)
Requesting Gravatar...
I have been reviewing your series on "Lets Build a Dev shop" Following right along until I hit BDD - I will have to research that a bit. I am a big proponent of Agile and have been doing that with my contract work and it loving it, as well as my customers. btw - I am in your neighborhood. I do .net developement on a contract basis and build web apps for Gardner Schools. I will be at HDC09 - I will touch base with you there
Left by Brent VanDusen on Sep 28, 2009 5:05 PM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: