Unity competitors

Feb 29, 2008 at 4:58 PM
Guys, can anyone give at least one reason why to use Unity instead of Windsor (http://www.castleproject.org/) or Spring.NET (http://www.springframework.net). I don't want to hurt anyone. Just at the moment I'm thinking about choosing IoC technology for my project. And it's very diffucult to choose. Microsoft P&P team's authority makes me prefer Unity, but I can't find any reason why it's better than mentioned frameworks. In the same time they have much more features.
Thanks in advance.
Feb 29, 2008 at 5:58 PM
Given ALL the information you provided to base my decision, I'd say go with Windsor (or Spring.net for that matter).

But if you tell me you're going to use an IoC container, EntLib 4, ASP.NET MVC or Prism and want to play community contributions... I'd say try Unity, play with it, wait for some more code drops (it's supposed to be released in 2 weeks).

I've been using Windsor extensively and it works like a charm... However Unity has a nice extension model. Once it is released and EntLib4 is out, I'd expect to see many contributions coming up as they are technologies capable of reaching a much bigger community than any O.S. project has been able so far.
Feb 29, 2008 at 6:32 PM
We're not asking you to choose us. Unity exists for a couple of reasons, but none of them have anything to do with world domination, honest. ;-)

If Windsor, Spring.NET, or any of the other existing IoC containers suit your needs better, by all means go with them. The hope is that by designing our future deliverables with an explicit container, p&p releases will be easier to use for folks using other containers too.
Feb 29, 2008 at 7:00 PM
Have you look at Windsor's extensibility model?

Feb 29, 2008 at 7:14 PM
Thank you for answers, guys.
2francois_tanguay: yes, I'm going to use EntLib4.
I got you ctavares, Unity will help to use EntLib for guys who already has eddicted to some IoC containers. Ok.
I just believed that before you started working on Unity you looked closely at these frameworks. And you may found some disadvantages and that's why you decided to develop own IoC.
I realize that you don't attempt to trample down all other IoC containers and never even have said that Unity is competitor for them. If I had been working already with some IoC, no questions would be. But I ain't.
I guest it will be common question: Unity+ObjectBuilder vs. Spring/Windsor/StructureMap/etc.

Feb 29, 2008 at 9:59 PM

Unity's creation doesn't have much to do with problems found on other IoC.

From what I understand about EntLib 4, they will use the same container abstraction model as Prism, so you could plug whatever into it.
Feb 29, 2008 at 10:40 PM

Honestly, probably not enough.

But don't get me wrong, I love Windsor. If you had been there during the Workshop at Redmond, you'd have seen me talking about how Windsor does some things well and why they should be incorporated into Unity.

The point I was trying to make was more that if you're to use technologies that already ship with Unity then at least try it, find the flaws and see by yourself how Windsor or Spring.net can help you.

IMHO, the worst thing you could do is try mixing multiple IoC containers withing one application.
Mar 3, 2008 at 5:16 PM

EvilShrike wrote:

I got you ctavares, Unity will help to use EntLib for guys who already has eddicted to some IoC containers. Ok.

From my understanding, it will be Prism and EntLib's introduction of a DI interface that will allow people using other containers to more easily use the new assets. I'm not sure how Unity itself would contribute to this ... unless IUnityContainer is going to be the interface by which you get to other containers. From the code I've seen so far, it won't be.

Mar 3, 2008 at 7:33 PM
Unity helps US (p&p) to build container friendly assets because we'll have a consistent container to build our future assets against. Rather than one-offing DI every time (and doing something weird) we can use it the same way. And since Unity is a lot like other containers, it'll let us build stuff that can more easily swap out for a different container.
Mar 3, 2008 at 7:43 PM
That only works if you have a container abstraction in place.
That goes both for not tying yourself to the Unity interface and to its creation.
For that matter, defining a cross cutting container interface isn't that easy, because of the different behaviors in edge case scenarios.

In other words, it is not enough to say: Use this container and then we can replace it.
Mar 3, 2008 at 11:56 PM

I would agree that they would have a tough time creating a generic interface applicable for all containers, but from my understanding that isn't their goal. They are only creating these interfaces for their own code which I imagine will only use the most common scenarios (e.g. Register<IMyType, MyType>(), Get<IMyType>, SetSingleton(), etc.) Their interface wouldn't be what you would want to use directly for your own needs, but it should be sufficient for plugging in the major containers to get Prism and EntLib to work.