mark.seemann (383) [Avatar] Offline
In the current table of contents, chapter 12 is listed as covering the DI Container. On the other hand, the table of contents currently lack a chapter on Ninject.

Since the original table of contents was published, I think I've seen a surge of interest in Ninject, both here in the forum and elsewhere. On the other hand, the interest in seems very limited.

For this reason I am considering replacing with Ninject, so that chapter 12 will cover Ninject and there will be no coverage of What do all of you MEAP readers think about that idea?
DerekC (71) [Avatar] Offline
Re: Replacing with Ninject
Tough call is my thoughts.

My first reaction was to visit their respective websites. Upon first visit to the Spring.Net website I thought the choice was going to be easy. Long time since last release, source repository not updated in the last 12 months.

However, following the link to the latest release takes you to a new site that requires you to register to download the code. So it would appear that Spring.Net is still under active development (a quick search for the new site confirmed this), but has gone 'Corporate' to some extent.

I would guess that Spring.Net is good choice if you come from a Java background or have a requirement for the full Spring.Net framework and not just the DI component. I suspect the quality and extent of the documentation is quite good given the environment it is being developed in (although I have not taken the time to verify this).

Ninject I think comes in the category of up and coming and I would agree that there is more buzz around Ninject than Spring.Net in the sections of the .NET community I frequent.

The bold claim on the front page is "Ninject makes dependency injection so easy that it becomes hard not to follow good practices." If the claim has any merit to it, then it may make a useful addition to the list of DI containers that you delve a bit deeper into. To have an DI implementation that is simple to understand would help in the learning process and when comparing it to other DI containers. However, I've not given Ninject more than a superficial look, so I don't know if it really does deliver on its claim.

The documentation is not currently very complete or detailed for Ninject (a number of pages say not yet updated for v2). Providing examples of common use cases for Ninject may well be of benefit to readers of your book in helping them get up and running with Ninject, where as someone wanting to use Spring.Net may get the support they need from the provided documentation.

As I started with, I think it is a tough call, and to some extent depends on what you consider the aim of the in-depth section to be and who you consider to be your target audience.
devlynx (6) [Avatar] Offline
Re: Replacing with Ninject
Since I use Ninject quite a bit, I think it is the right way to go. I'm sure that Spring.NET supporters would disagree, but it would make the book much more appealing to a lot of developers.
pmillsaps (2) [Avatar] Offline
Re: Replacing with Ninject
Personally I would prefer ninject, as it is on my current list of items to learn about. Though it might be nice to at least say a little about Spring.Net as an alternative library, that way readers could kind of decide for themselves which one met their needs.
sbohlen (3) [Avatar] Offline
Re: Replacing with Ninject
**disclaimer: I am a SpringSource employee involved in the Spring.NET project**

**second disclaimer: sorry for the length of this!**

I agree its a tough call smilie

As someone (recently) having become formally involved in Spring.NET I'd like to try to provide some clarification on several of the points mentioned here...

If you look at the FishEye report for the actual repo ( you should see plenty of activity in the past 12 months (with a sizable increase in the past 30-45 days). I suspect that if you are seeing 'no commits in the past 12 months' you are probably looking at the long-since-abandoned repo on SourceForge and this hasn't been the authoritative repository for Spring.NET for quite some time.

Version 1.3.0 was released last December (8 months ago) and we are nearing a 1.3.1 maintenance release within the next 30 days or so. In the world of OSS projects (DI containers included), 8-9 months between official releases doesn't seem that unusual to me. A quick review of several other (semi-)prominent .NET OSS projects shows that many go significantly *longer* between even unofficial point releases.

You are definitely not required to register in order to download the Spring.NET framework. From the download link you are directed to a registration page where you are encouraged to register (in order to receive notification of Spring.NET-related offers, updates, and more) but near the submit button you should see a "skip registration and just proceed to download" link designed to support 'anonymous' download of the framework if that better suits people's needs.

From nearly its inception in 2004 the Spring.NET framework has been an effort guided and supported by SpringSource (the same organization responsible for doing the same for the Spring Framework for Java) and so I don't see Spring.NET as being really any more 'corporate' today than in its past. I am curious about the implied concern about Spring.NET receiving 'corporate' support in any case as IMO having a corporate sponsor behind an OSS project merely *decreases* the chances that such a project will become abandon-ware as its authors inevitably grow interested in other things over time and the project falls into disrepair.

If anything, I would think that having a corporate 'sponsor' should *improve* an OSS project rather than impede it. One actually finds that this state of corporate sponsorship/stewardship of OSS projects tends to be the norm rather than the exception in nearly every other software ecosystem (Java, Python, PHP, Ruby, etc.) making its relative absence in the .NET OSS ecosystem all the more glaring. IMO its one of the factors that contributes to the continuing (relatively) low levels of acceptance of OSS in the .NET space and actively impedes the growth of adoption of otherwise quite valuable .NET OSS projects.

This isn't to suggest that OSS projects without corporate stewardship are in any way technically inferior, less dependable, or otherwise 'bad', but merely to point out that having corporate stewardship is neither unusual in other ecosystems nor a reason for concern in the .NET ecosystem as your comment would seem to hint at.

All that said, I would tend to agree with your observation that the buzz surrounding things like Ninject tends to eclipse that surrounding 'old standbys' like Castle Windsor, or Spring.NET. That's certainly a factor when considering what to focus on.

Also, re: which of all of these represents a shallower learning curve, I also tend to agree that something like Ninject is more approachable for a few reasons:
* its API isn't "old" (in that it doesn't carry any legacy baggage from the olden days where there weren't things like lambdas, etc. even if by now the API may have added such more modern niceties)
* its trying to do just one thing (e.g., DI) rather than be part of a larger system (Castle Project, Spring.NET, etc.)

This perhaps makes something like Ninject a better choice if the goal is to teach DI "in a vacuum" but not (perhaps) the best choice if there's an idea about looking at DI in the context of how it might interact as one of the underpinnings of a larger framework (e.g., Castle Project, Spring,NET, etc.).

I tend to agree that this comes down to a question of "what's your audience?" combined with "what are you trying to get across to the reader?". If the goal isn't to teach any specific DI framework but to select a framework that provides the best way to get concepts across then these questions are probably more important decision points than "what's got the popular attention of the moment?".

Hope this helps some and I apologize in advance for the length~!

Best of luck with the book -- I'm looking forward to it (regardless of which container is selected as the focus of this chapter smilie )
DerekC (71) [Avatar] Offline
Re: Replacing with Ninject
Fellow readers, this is largely off topic, so feel free to skip.


I think you are reading more negativity into my post than was intended smilie

The first paragraph was all in reference to the SourceForge site. It is unfortunate that the SourceForge site does not indicate that it has been abandoned and where I should be looking instead.

Having found the new website ( I moved on to paragraph 2. The reference to having 'Gone corporate to some extent' reflected my impression that it had moved from SourceForge to a commercially backed site and was not particularly meant to be negative. In fact I suggested that the documentation quality was likely to have benefited from this.

There are a few things about the new site I find puzzling:

* The gap between the "Older News" and "Source Forge Project" tends to make the "Source Forge Project" link more prominent which is unfortunate given that it has been abandoned. (In fact I think that is the route by which I reached the SourceForge project).

* If I click the Downloads link, then click the link for the latest production release it takes me to a page requesting my personal details. All the other download links on the downloads page take me to what I actually wanted, the software.

Nothing tends to put me off casual browsing faster than being asked for my personal details. Since I was only casually browsing I wasn't prepared to sign up for potential correspondence I may not want. Don't take this personally, it is impossible to tell exactly what you will be sent anytime you provide your details to someone else. I didn't get as far as the cleverly camouflaged "skip registration and just proceed to download" link. Something as simple as having the skip button the same size as the proceed button would have been enough to prevent me terminating the process. If I look at a product and like it, that is when I would usually consider signing up.

Apologies if you felt I was putting Spring.Net down, that was not my intention. However, I do think there are a few simple things the project could consider that may make it less likely potential adopters will be put off before they've actually evaluated the product.
sbohlen (3) [Avatar] Offline
Re: Replacing with Ninject
**also off-topic so last comment on this**


Thanks for the feedback/input; I appreciate your clarifying your intent and I apologize if I read it in an overly negative light. Text can be oh-so-terrible a medium for conveying tone smilie

The very fact that your (brief) investigation into Spring.NET turned up all of those (easy to see why) misconceptions about the project serves to point out that the messaging and other aspects of the project need some "tender loving care" in order to prevent others from drawing the same conclusions. I was under the impression that the SF site had a note about its removal from the role of central repository and 'hub' for the project but the fact that you cannot (easily) find this information proves that this probably isn't nearly as clear as it really needs to be.

I appreciate your taking to the time to have this conversation and your feedback/impressions/reactions are important for us to take into account when trying to craft a better new-user-investigating-the-framework experience for our (potential) adopters.

Thanks again (and sorry again for all here for briefly slipping off-topic)~! (47) [Avatar] Offline
Re: Replacing with Ninject
I was rather keen on reading the Spring.NET chapter!
wtheronjones (4) [Avatar] Offline
Re: Replacing with Ninject
I will say that I just passed on a contract position that utilized the Sprint.Net framework (passed on the short termness of it, not the Spring.Net smilie ).
One more anectdotal posting and we'll have some real data here!

What about a chapter on each? Or choosing a different sacrificial lamb?

I'm mostly looking forward to the MEF chapter to be honest, but look forward to seeing them all.
mark.seemann (383) [Avatar] Offline
Re: Replacing with Ninject
I would love to do both, but that's probably not realistic. Writing a chapter takes time, and we also want to print the book at one time.

Sacrificing Castle Windsor or StructureMap is not an option because these are some of the most widely used DI Containers. Also: the chapters are already written smilie

The Autofac chapter is also almost done, so that's not an option either.

Then should we sacrifice Unity? I don't think so. All anecdotal evidence I see so far is that Unity interests a different audience than the other containers. Because it's a Microsoft container (even if only from p&p) it introduces new developers to the wonderful world of DI, and they will subsequently look after a book that can assist them, so dropping the Unity chapter would, in my opinion, be a spectacularly bad business decision.

Then should we sacrifice MEF? Some of MEF's creators have publicly stated that it's not a DI Container at all. I tend to agree. On the other hand, it now ships as part of .NET 4 so I think the Unity argument applies here as well.

In any case, based on the feedback I've received so far, I'm currently inclined to keep and (unfortunately) not cover Ninject.
robsosno (1) [Avatar] Offline
Re: Replacing with Ninject
I'm glad that Spring.NET remained. My argumens for it are:
1. Exchanging experience with java teams within company (Spring, Hibernate)
2. The strong side of Spring.Net is not DI (because of XML-only configuration). However it has quite good AOP interceptors. The most important in Spring.Net are "facilities" (in Windsor terminology) which provide ready to use thin DI API around other native APIs. We are using ADO.NET, NHibernate and WCF Web facilities.
As an example in WCF Web I've centralized error handling (creating custom SoapFault) in one place: in interceptor of a service implementing ServiceContract. Also I haven't seen better WCF Web integration than in Spring.Net.
So for me Spring.Net is important DI Container despite of its configuration issues.
I'm also thinking of combining StructureMap for Ioc and Spring.Net for Aop and facilities (not tried yet).
mark.seemann (383) [Avatar] Offline
Re: Replacing with Ninject
Thank you for writing. I register this as another vote for keeping the Spring.NET chapter.

To clarify: I wrote that I'm inclined to keep Spring.NET - not that I will, guaranteed, keep it. However, with your voice in the mix, I'm a little more inclined than I was before smilie
wtheronjones (4) [Avatar] Offline
Re: Replacing with Ninject
Well, hopefully MEF will make the cut. I don't know of any books out there yet that have MEF in it yet, & it'll probably be a pretty big thing now that it's in the framework.
BeauGeek (1) [Avatar] Offline
Re: Replacing with Ninject
This is a vote for Ninject -- if the issue hasn't been decided yet. It's what I use, and seems to very popular and is being actively developed, with lots of interaction with the developers on the forums.


SammyG (6) [Avatar] Offline
Re: Replacing with Ninject
+1 for Ninject.

Perhaps cover spring in a blog or additional downloadable appendix for people who bought the book.
drohm (1) [Avatar] Offline
Re: Replacing with Ninject
+1 for Ninject.
octavio08 (8) [Avatar] Offline
Re: Replacing with Ninject
+1 for Ninject
mark.seemann (383) [Avatar] Offline
Re: Replacing with Ninject
Thank you, all, for your thoughts and interest in this question. Right now I think the posts here represents a fairly equal interest in Ninject and Spring.NET.

I believe that I'm going to move forward with Spring.NET, so I'll have to disappoint all those people who wanted to see coverage of Ninject. However, please consider my reasoning outlined below:

First of all we originally announced the Table of Contents with Spring.NET covered in chapter 12 (and no Ninject coverage). While we could change the ToC later on, the fact that many people have already bought the book through the MEAP means that we need to have a pretty compelling reason before we can do that. A more or less equal interest in Ninject vs. Spring.NET does not, IMO, in itself constitute a massive demand for Ninject instead of Spring.NET.

A second, almost as important, reason is that the book was never intended as a manual for any particular DI Container. If I do my job well, the principles and patterns outlined in parts I-III should be able to stand the test of time. They should also be applicable five years from now. For each DI Container, on the other hand, I can almost guarantee that at least one of the chapters will be 'old' when the book comes out in print. Some OSS projects just move that fast.

When I originally selected DI Containers for part IV, I used a couple of selection criteria. First of all, I think that it is essential to cover the two big OSS containers (Castle Windsor and StructureMap). Unity and MEF, originating from Microsoft, are also more or less mandatory. This only leaves two chapters for other containers.

From my cursory inspection, I find Ninject to be rather similar to Autofac (which is already covered in chapter 13) in style, so using up a whole chapter on something similar would not be the best use of the available space.

Spring.NET is very much different, so I find it more relevant to use the remaining chapter covering that, as it gives readers a more diverse view of the DI Container space.

It's too bad that I can't cover Ninject as well, but there will always things that must be left out. The book also doesn't cover Funq, LinFu, Lightspeed, OCInject or whatever else there may be out there.
Maslovian (31) [Avatar] Offline
Re: Replacing with Ninject
While I do agree MEF isn't exactly a DI framework, I would really love to have it in your book as it does address some of the concerns of DI in a different way. I was hoping for ninject as I have used it just once so far and found it splendid. I have done 2 parts with MEF and been VERY happy with how it works.
tjaskula (51) [Avatar] Offline
Re: Replacing with Ninject

Leave it like it is today. No need to change. Most important is to not sacrify MEF chapter smilie
davidcornish (5) [Avatar] Offline
Re: Replacing with Ninject
Disappointed to see that NInject won't be covered, as I came to the forum to ask about this, but perhaps some further info on NInject could be included as a download to go with this book?
mark.seemann (383) [Avatar] Offline
Re: Replacing with Ninject
The purpose of this book is not to act as documentation for any DI Container. Even for those covered, there's a good chance that parts of certain chapters will be obsolete quickly - if I knew which ones, I'd consider cutting them.

The purpose of the book is to teach general principles and patterns about DI. If you understand those, you should be able to get up to speed with any DI Container quickly - including Ninject. They are not that different from each other, and most of the advanced features you shouldn't need anyway.

Even if I did include 'further info on Ninject' as a download, that would take months to produce. Would that help you? What is it that you think this book will be able to cover that you can't get from the Ninject site (

Don't get me wrong: given unlimited time and resources, I would love to include a chapter on Ninject as well, but as it is, my editor is already getting impatient.
grantpalin (13) [Avatar] Offline
Re: Replacing with Ninject
This has been interesting thread to watch. I've found the variety of .NET IoC containers slightly offputting, and it's good to see that a handful of them are being documented in some depth. I do like the way you are pointing out the good points and the not-so-good of each.

Your reasoning in this thread re. Ninject vs Sprint.Net seems sound - and you are the writer, after all! I understand that you couldn't possibly cover more than a handful of containers in depth...that said, perhaps you might consider doing a brief appendix listing other container options, and giving a few lines of description to each, along with a point or two on how they resemble or differ from other options. Or even just a listing of the names and websites, just enough to make readers aware of the options.
mark.seemann (383) [Avatar] Offline
Re: Replacing with Ninject
Yes, a list of other DI Containers is definitely part of my plan. How much more than that I can deliver, I don't yet know.
larryq (46) [Avatar] Offline
Re: Replacing with Ninject
I wouldn't sweat Ninject. I've used it but it's not vital that it be in the book-- you've got plenty of other DI containers in there. You'll drive yourself crazy if you try to cover every base and there's no reason for it.

You've got the right balance-- DI theory, followed by coverage of some existing products. As for dealing with or even mentioning every product out there, forget it. The theory is the most important aspect, as the containers themselves will be out of date before any of us likes to think about! The book is great as is, I'd tie up the loose ends, spit and polish and edit, and put 'er out there.
mark.seemann (383) [Avatar] Offline
Re: Replacing with Ninject
Thanks for your comment.

That's pretty much my take on the situation as well. FWIW, I'm currently writing the Spring.NET chapter, which is the last remaining chapter.
Kalli (3) [Avatar] Offline
Re: Replacing with Ninject
From Barcelona (Spain) 1 more for Ninject in your book. Ninject is nice... and your book fabulous. Congratulations, Mark !!!!
Patrick Szalapski (2) [Avatar] Offline
Betcha wish ya'd done it! So when's the second edition coming out?
434402 (1) [Avatar] Offline
+1 for Ninject smilie