ASP.Net MVC + StructureMap Woes Solved!

In terms of an IoC container, my component of choice is StructureMap. Compared to other components available, StructureMap is purely IoC. Additionally, it can also be used without a configuration file.

I’ve been playing around with the ASP.Net MVC, namely in regards to its extensibility and how it can be simplified. I found that the MVCContrib project has already implemented StructureMap as an IoC container, but with a critical flaw – you have to register all of your concrete controller types individually! A much better solution would be similar to how they did the Windsor implementation, where each controller type is dynamically added to the container.

So I set out to do just that…only to end up spending way too much time running into dead ends. I found many resources on the interweb about using the StructureMap config file, but no where did I find the code-equivalent of the same thing. To further complicate the issue, the fluent interface of the StructureMapConfiguration class does not expose a way to send a concrete Type in – you could only do it via generics, which again defeats dynamically populating the container.

Finally, after scouring the StructureMap source code, I found a solution. The key to configuring the container is the IExpression interface. The following snippet shows an implementation that creates the controller plugin family, searches the assemblies in the bin directory for controllers, and adds them to the family as plugins.

Controller Expression

Using a custom Registry class to introduce the custom expression, we can now do the following:

Controller Registry

Now we’ve got StructureMap creating our controllers!

This sure seems like a lot of work just to be able to add plugin types dynamically. Hopefully future versions of StructureMap can address the configuration interfaces to allow types to be passed in rather than using generics.

Download the source

in Blog | 305 Words

.Net Framework Spotlight: yield

As the .Net Framework continues to evolve, its growth often hides useful features. Joshua Flanagan has an excellent post regarding the yield keyword, which was introduced in .Net 2.0. The yield keyword allows you to return IEnumerable<T> without actually building a concrete collection. Joshua points out 2 of the top benefits of yielding…

This has at least 2 very important implications for the method that returns the IEnumerable<T>:

1) It does not need to build up a big list of all of the items it plans to return, holding them all in memory at the same time. If the list of items is very large, holding them all in memory at once can be a significant burden.

2) It does not necessarily need to do the work to produce all of the items in the list. If the caller breaks out of the foreach loop before the entire collection has been traversed – all of the work needed to produce the remaining items in the colleciton is avoided. Without using the yield keyword, you would have to build up the entire collection to return, even if the caller was only going to look at the first few items.

As with every feature, there are times to use it, and times to avoid it, as Fritz Onion points out. Thankfully that’s why developers are still needed to tell the computer what to do!

in Blog | 233 Words