Deal of the Day

Home » Main » Manning Forums » 2009 » Dependency Injection in .NET

Thread: Replacing Spring.net with Ninject

Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 26 - Pages: 2 [ 1 2 | Next ] - Last Post: Jun 3, 2011 5:20 AM by: Kalli
mark.seemann

Posts: 383
Registered: 10/4/09
Replacing Spring.net with Ninject
Posted: Aug 4, 2010 6:44 AM
  Click to reply to this thread Reply

In the current table of contents, chapter 12 is listed as covering the Spring.net 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 Spring.net seems very limited.

For this reason I am considering replacing Spring.net with Ninject, so that chapter 12 will cover Ninject and there will be no coverage of Spring.net. What do all of you MEAP readers think about that idea?

DerekC

Posts: 71
From: United Kingdom
Registered: 8/4/10
Re: Replacing Spring.net with Ninject
Posted: Aug 5, 2010 5:39 PM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

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

Posts: 6
Registered: 11/8/09
Re: Replacing Spring.net with Ninject
Posted: Aug 5, 2010 7:32 PM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

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

Posts: 2
From: Waco, Texas
Registered: 12/7/09
Re: Replacing Spring.net with Ninject
Posted: Aug 6, 2010 7:42 AM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

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


Posts: 3
From: New York, NY
Registered: 8/6/10
Re: Replacing Spring.net with Ninject
Posted: Aug 6, 2010 9:26 AM   in response to: DerekC in response to: DerekC
  Click to reply to this thread Reply

**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 :)

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 (https://fisheye.springsource.org/changelog/spring-net) 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 :) )

DerekC

Posts: 71
From: United Kingdom
Registered: 8/4/10
Re: Replacing Spring.net with Ninject
Posted: Aug 6, 2010 3:29 PM   in response to: sbohlen in response to: sbohlen
  Click to reply to this thread Reply

Fellow readers, this is largely off topic, so feel free to skip.

SBohlen,

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

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 (http://www.springframework.net/) 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


Posts: 3
From: New York, NY
Registered: 8/6/10
Re: Replacing Spring.net with Ninject
Posted: Aug 6, 2010 6:57 PM   in response to: DerekC in response to: DerekC
  Click to reply to this thread Reply

**also off-topic so last comment on this**

DerekC:

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 :)

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)~!

ying-hui.the@wi...

Posts: 1
From: London, England
Registered: 8/9/10
Re: Replacing Spring.net with Ninject
Posted: Aug 9, 2010 3:42 AM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

I was rather keen on reading the Spring.NET chapter!

wtheronjones

Posts: 4
From: San Diego, CA
Registered: 8/22/10
Re: Replacing Spring.net with Ninject
Posted: Aug 22, 2010 5:48 PM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

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 ;) ).
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

Posts: 383
Registered: 10/4/09
Re: Replacing Spring.net with Ninject
Posted: Aug 23, 2010 9:05 AM   in response to: wtheronjones in response to: wtheronjones
  Click to reply to this thread Reply

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 :)

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 Spring.net and (unfortunately) not cover Ninject.

robsosno

Posts: 1
Registered: 8/23/10
Re: Replacing Spring.net with Ninject
Posted: Aug 23, 2010 2:40 PM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

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

Posts: 383
Registered: 10/4/09
Re: Replacing Spring.net with Ninject
Posted: Aug 23, 2010 3:16 PM   in response to: robsosno in response to: robsosno
  Click to reply to this thread Reply

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 :)

wtheronjones

Posts: 4
From: San Diego, CA
Registered: 8/22/10
Re: Replacing Spring.net with Ninject
Posted: Aug 24, 2010 12:25 AM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

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

Posts: 1
Registered: 8/25/10
Re: Replacing Spring.net with Ninject
Posted: Aug 25, 2010 10:27 AM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

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.

Thanks!

Vikram

SammyG

Posts: 6
From: Cape Town
Registered: 8/27/10
Re: Replacing Spring.net with Ninject
Posted: Sep 20, 2010 5:50 AM   in response to: mark.seemann in response to: mark.seemann
  Click to reply to this thread Reply

+1 for Ninject.

Perhaps cover spring in a blog or additional downloadable appendix for people who bought the book.

Legend
Gold: 300 + pts
Silver: 100 - 299 pts
Bronze: 25 - 99 pts
Manning Author
Manning Staff
Manning Developmental Editor