Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Nick
Is this you? Claim Profile »
9 months ago
in Public Service Announcement - Miguel de Icaza on Miguel de Icaza's blog
Yes!
1 reply
9 months ago
in Comparing .NET DI (IoC) Frameworks, Part 2 on Andrey Shchekin's Blog
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?
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?
1 reply
Andrey Shchekin
The use case is to create a factory which registers several factory-specific components without polluting the original container with these components and their local scope dependencies (such as connection data). I describe the problem in detail at http://blog.ashmind.com/index.php/2008/06/23/di... .
So, if I can create a container in place and then throw it away, it also solves the pollution problem.
So, if I can create a container in place and then throw it away, it also solves the pollution problem.
9 months ago
in Comparing .NET DI (IoC) Frameworks, Part 2 on Andrey Shchekin's Blog
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.
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.
1 reply
Andrey Shchekin
Sure, I like the second approach much more.
By the way, is it possible to resolve unregistered types in Autofac?
I do not feel that is very important, given hierarchical containers, but I am still interested.
By the way, is it possible to resolve unregistered types in Autofac?
I do not feel that is very important, given hierarchical containers, but I am still interested.
9 months ago
in Comparing .NET DI (IoC) Frameworks, Part 2 on Andrey Shchekin's Blog
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
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
1 reply
Andrey Shchekin
Thanks!
You have a very interesting implementation.
I would prefer to have an automatic registration by default, since if I get into situation where I would need more than one ILogger collection, I would probably use some kind of contextual override for a requiring component anyway. But it is a question of preference.
There are only two things that I feel are missing in your implementation -- support for IService[] (since it is simplest way to define collection dependency) and and ability to register collections using non-generic API.
Due to the first one, I can not update tests to pass right now, however, I had fixed the chart and will fix the post text as well.
You have a very interesting implementation.
I would prefer to have an automatic registration by default, since if I get into situation where I would need more than one ILogger collection, I would probably use some kind of contextual override for a requiring component anyway. But it is a question of preference.
There are only two things that I feel are missing in your implementation -- support for IService[] (since it is simplest way to define collection dependency) and and ability to register collections using non-generic API.
Due to the first one, I can not update tests to pass right now, however, I had fixed the chart and will fix the post text as well.
10 months ago
in Is this Better than Constructor Injection? on Emad Ibrahim
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
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
- 2 points
- Jump to »
eibrahim
Ok that makes perfect sense and was sort of what I was thinking but you expressed it much better.
I guess if you are writing a framework or code that will be used by others then it makes sens to go with constructor injection because it is explicit what interfaces are the class dependent.
If I used a property that automatically creates the interface from IoC container i.e. Kernel.Get...., it will work just the same but then the consumer of that class doesn't know that. He doesn't know which interfaces need to be configured in his IoC container configureation and so on...
What if we can configure a class like this:
[Inject(IService1, IService2, IService3)]
class MyClass
This way, I don't have to "pollute" my constructor and it is still somewhat discoverable and predictable. What do you think?
I guess if you are writing a framework or code that will be used by others then it makes sens to go with constructor injection because it is explicit what interfaces are the class dependent.
If I used a property that automatically creates the interface from IoC container i.e. Kernel.Get...., it will work just the same but then the consumer of that class doesn't know that. He doesn't know which interfaces need to be configured in his IoC container configureation and so on...
What if we can configure a class like this:
[Inject(IService1, IService2, IService3)]
class MyClass
This way, I don't have to "pollute" my constructor and it is still somewhat discoverable and predictable. What do you think?
10 months ago
in The Best IoC Container? on Emad Ibrahim
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
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
1 reply
eibrahim
I don't have anything specific. But a small suggestion, I wasn't sure which
version to use. One version said Release 1.2.7 for .net 2.0 and the other
said Release 1.2.7... Which .net version is that one? 1? 1.1? 3.0? 3.5? I
assumed it was 3.5 and downloaded that one.
Also when I tried to integrate it into my asp.net mvc project according to
your wiki on MvcIntegration, I am supposed to reference
Autofac.Integration.Web.Mvc.dll - which is no where to be found and there
was no link to download it anywhere...
So, I figured if things are going to be that hard to get started and find
things, they will be a lot harder when I have a serious issue down the road.
I hope that helps.
PS: I am willing to give it another shot if you can point me in the right
direction.
version to use. One version said Release 1.2.7 for .net 2.0 and the other
said Release 1.2.7... Which .net version is that one? 1? 1.1? 3.0? 3.5? I
assumed it was 3.5 and downloaded that one.
Also when I tried to integrate it into my asp.net mvc project according to
your wiki on MvcIntegration, I am supposed to reference
Autofac.Integration.Web.Mvc.dll - which is no where to be found and there
was no link to download it anywhere...
So, I figured if things are going to be that hard to get started and find
things, they will be a lot harder when I have a serious issue down the road.
I hope that helps.
PS: I am willing to give it another shot if you can point me in the right
direction.
1 year ago
in Ninject Lives! on Discord & Rhyme
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
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
1 reply
nkohari
I was considering using Beanstalk for keeping some of my other projects (which are too messy to release as legitimate open-source). Unfortunately it looks like the pricing model's not the greatest for that, anyway. I was originally attracted by the nice integrations they support -- for example, Twitter. :)
Its a matter of preference which is why it is optional. Learn to adapt.