Disqus - Latest Comments for Nick

Re: Coming Up For Air

Nick — Mon, 12 Nov 2007 05:36:36 -0000

@ShaunC, if you dig into Ninject you'll find it is quite different to Windsor. Windsor is great but the open source culture thrives on diversity.

container.Bind().To();

.. is easier on my eyes (and wrists.) By the gradual accumulation improvements we move on. In five years, will we all be using Windsor? I never thought it would happen, but no sooner has Subversion reached mass acceptance than we're moving on to Git/Darcs/Mercurial/Bzr....

Nate, do you think it is possible a 'standard' container configuration API will emerge the way JPA did? Perhaps something like that would turn into a lowest-common-denominator approach. It couldn't hurt to have a standard API for the commonest scenarios like the one above though......??

Re: Coming Up For Air

Nick — Sun, 18 Nov 2007 04:01:56 -0000

Nate, guess that is a fair stumbling block :) As you've pointed out, most of the decision to use one container over another revolves around the API.

Modules might play a big part in some people's decisions - e.g. if I'm using NHibernate then a pre-built NHibernate module will make a particular container more attractive.

99% of registrations in any container will be (name, type, service, lifecycle) - perhaps a common adapter onto a minimal subset of each container API would be enough that we could write many modules in a container-agnostic fashion?

I can see a stumbling-block or two (or three) here of course, but it would be really neat to be able to use a single module implementation on Ninject, Windsor, or whatever. I'm probably dreaming big-time :)

Sounds like a really interesting project you're working on, BTW.

Re: Ninject Lives!

Nick — Wed, 12 Mar 2008 18:00:40 -0000

Nice. That technique - using overloads on 'Parameters' rather than on Get() to provide the different types as arguments - is great for flexibility while keeping interface bloat on IKernel down. Easier to navigate than extension methods, too. Something for the toolbox...

Glad to see you're back at it. Curious why you're considering Beanstalk rather than Google Code though? Regardless, you might also want to have a look at cvsdude.com (yes, they host Subversion) - I love Trac, so glad to see it hosted. They're also just down the road from me :)

Cheers,

Nick

Re: Ninject 1.0 Goes Gold

Nick — Tue, 17 Jun 2008 07:16:40 -0000

Congratulations, Nate! So much hard work has obviously gone in to make Ninject a really innovative yet polished piece of code. I'm only surprised you didn't bump up the revision number earlier :)

Re: Joining the Telligenti

Nick — Thu, 21 Aug 2008 16:57:02 -0000

Cool stuff Nate! Can't wait to see what comes out of this combination :) All the best!

Re: Zen and the Art of Project Management

Nick — Tue, 09 Jun 2009 23:18:07 -0000

Wow! I didn't see that coming, although your absence from the online world has been conspicuous :) Sounds like a great product.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nick — Mon, 22 Sep 2008 10:36:11 -0000

Hi Andrey,

Wow! It is very interesting to see a methodical approach to this comparison.

Autofac does also support list registrations - but like 'resolve anything' you have to opt-in. See: http://code.google.com/p/autofac/wiki/Collections.

As you've hinted at - like most containers you can change this behaviour by writing custom extensions. In general, you'll find Autofac is very conservative about working absolutely predictably by default.

Cheers,

Nick

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nick — Mon, 22 Sep 2008 10:42:40 -0000

Aaah - and regarding automatic registration - you can always do:

builder.RegisterTypesAssignableTo<object>();

:) Not really recommendable though.

I recently ported some Prism code from Unity to Autofac, and used something similar to:

builder.RegisterTypesMatching(t => t.Name.EndsWith("View"));

--- just to illustrate that there is no need to use tagging interfaces or inheritance in order to work with this feature.

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nick — Wed, 24 Sep 2008 17:12:26 -0000

The net effect is almost the same. RegisterTypesMatching() and RegisterTypesAssignableTo() are lazy - there is no scan of loaded assemblies, for instance.

You could always create an extension method ResolveUnregistered() which could check/register first, too.

Not sure what you mean about hierarchical containers relating to this use case - can you clarify a little?

Re: Comparing .NET DI (IoC) Frameworks, Part 2

Nick — Wed, 24 Sep 2008 23:29:51 -0000

On IService[] - point taken, issue raised. In the meantime you can do:

builder.Register(c => c.Resolve<IEnumerable<X>>().ToArray());

..in order to adapt the default collection type onto an array type.

I'll look into the non-generic collection registrations - may look into that in the future if there is demand.

Thanks for the feedback!

Re: Public Service Announcement - Miguel de Icaza

Nick — Sun, 28 Sep 2008 19:08:34 -0000

Yes!

Re: The Best IoC Container?

Nick — Tue, 19 Aug 2008 16:59:18 -0000

Hi Emad,

Any suggestions for making Autofac more approachable? Documentation is an endless task, but I'd love to know where the API might be improved to make it more 'discoverable'.. :)

Cheers,

Nick

Re: The Best IoC Container?

Nick — Tue, 19 Aug 2008 19:32:45 -0000

Hi Emad,

Thanks for the suggestions. I've updated the name of the download to "Release 1.2.7 for .NET 3.5" (your assumption was correct.)

Regarding Autofac.Integration.Web.Mvc.dll - it is in the /bin folder contained within the zip file (featured on the front page - should have been the file you downloaded.) All of the Autofac assembiles should be included in the same download.

I'd love to hear how you go if you have another shot. The http://groups.google.com/group/autofac group is always a good place to ask any questions you come up with.

Cheers!

Nick

Re: Is this Better than Constructor Injection?

Nick — Sat, 30 Aug 2008 19:03:56 -0000

The benefit that ctor injection brings is more about predictability than discoverability.

It isn't so obvious when you're in 'author' mode, because at that point you're intimately familiar with the class's internals and don't find any of its interactions with the rest of the system 'surprising'.

As a user or maintainer of a class, however, you need to be aware of both the provided interfaces, and the required interfaces *equally*. Otherwise, you can have a very hard time when trying to determine exactly how methods called on that class will affect the rest of the application.

Provided interfaces -> interface implementations
Required interfaces -> constructor parameters

The second isn't necessarily any less important than the first.

(Properties can't be used to emulate the same role, as it is impossible to determine from a property declaration whether the property represents a required interface or just exposes functionality provided by an aggregated component.)

Hope this helps!

Nick

Re: Is this Better than Constructor Injection?

Nick — Tue, 02 Sep 2008 19:52:14 -0000

Starting to get well into 'service locator' territory here - there's a lot of discussion out there about the relative merits of each.

Re: Sorting Algorithms: The Comb Sort

Nick — Sun, 14 Sep 2008 11:22:35 -0000

Hi Oj!

Interesting one mate. Hadn't heard of comb sort before... Something new every day :)

One thing I'd love to see in these articles is some kind of 'timeline of invention' - i.e. you talk about Comb Sort improving on Bubble Sort - it would be great to know how long it took for this algorithm to emerge, and who put the work into designing it.

Given the different space requirements, I guess I'm most curious to find out whether this was developed after Quicksort...

Have a good Monday! (Still enjoying Sunday here!)

Nick