Resolving component without registering it in container

[ashmind]

Consider the following code:
public class MyClass {
public MyClass(IService1 s1, IService2 s2, ...) {
}
}

What is the easiest way to create MyClass using WindsorContainer
without adding it to the container?

[Ken Egozi]

var my = new MyClass(IoC.Resolve<IService1>(), IoC.Resolve<IService2>, ...);

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.musicglue.com
http://www.castleproject.org
http://www.mamaherb.com
http://www.gotfriends.co.il

[ashmind]

Sorry, I should have said that I thought about this solution.
However, it does not benefit from having container.
What I really want is to use container constructor resolution, etc,
but for class that is not registered.

Something like var my = container.Create<MyClass>();

On 27 май, 15:30, "Ken Egozi" <egoz...@gmail.com> wrote:
> var my = new MyClass(IoC.Resolve<IService1>(), IoC.Resolve<IService2>, ...);
>

[Andre Loker]

Hi,

> Sorry, I should have said that I thought about this solution.
> However, it does not benefit from having container.
> What I really want is to use container constructor resolution, etc,
> but for class that is not registered.
>
> Something like var my = container.Create<MyClass>();
>

Is there any why you cannot register the component at the container? If
you define "Transient" as the life style any call to resolve would
create a new instance of MyClass, just as in your code example.
container.AddComponentLifeStyle<MyClass>(LifestyleType.Transient);
..
var my = container.Resolve<MyClass>();

Regards,
Andre

[ashmind]

I do not want to put in the container, since it depends on other data
that makes sense only within a certain scope.
It will work inside a container, if I provide the data via
additionalArguments or other means.
But it fells like a container pollution -- putting in a class that no
other class should depend on and that can be resolved only within a
certain circumstances.

[Ayende Rahien]

This came up several times. We had a solution that wasn't satisfactory, auto registering in the container.
I think we need to have a solution for that.

One question, how are we going to handle caching of reflection information?

2008/5/27 ashmind <ash...@gmail.com>:

[ashmind]

For my specific case, performance is unimportant.

I think the reflection data can be cached by resolved Type, but I am
not sure what criteria are for choosing caching solution.
It may be possible to overload straightforward Type-based caching by
continuosly resolving different variants of the same generic.

On 27 май, 17:19, "Ayende Rahien" <aye...@ayende.com> wrote:
> This came up several times. We had a solution that wasn't satisfactory, auto
> registering in the container.
> I think we need to have a solution for that.
>
> One question, how are we going to handle caching of reflection information?
>

> 2008/5/27 ashmind <ashm...@gmail.com>:

[ashmind]

Simplest and slowest solution in case anybody needs it:
public static class MicroKernelExtensions {
public static T Create<T>(this IKernel kernel) {
return (T)kernel.Create(typeof(T));
}

public static object Create(this IKernel kernel, Type classType) {
var childKernel = new DefaultKernel { Parent = kernel };
childKernel.AddComponent(classType.Name, classType,
classType);

return childKernel.Resolve(classType);
}
}

This is ugly and *very* slow, 20 secs for 100000 Create vs 3 secs for
100000 Resolve for pre-registered component.
It is possible to add caching, and basic {Type => IKernel} caching
improves performance to be nearly equal to Resolve.

Since performance is not important for my case, and caching will
require good locking mechanism, I will use the above solution for now.

[Ayende Rahien]

This is also not valid when you are creating an item that requires dependencies from the container.

2008/5/28 ashmind <ash...@gmail.com>:

[Ayende Rahien]

I think that the best solution would be to create a new container for all of those, and link it as a child container to the root container.
That will allow resolving dependencies form the container.

2008/5/28 Ayende Rahien <aye...@ayende.com>:

[ashmind]

> This is also not valid when you are creating an item that requires
> dependencies from the container.

Actually, I think, { Parent = kernel } solves this.

> I think that the best solution would be to create a new container for all of
> those, and link it as a child container to the root container.

The single child container would be more performant, but components
will be able to depend on each other.
So, I think, if performance is less important, child container per
Create is better.

On May 28, 5:37 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> This is also not valid when you are creating an item that requires
> dependencies from the container.
>

> 2008/5/28 ashmind <ashm...@gmail.com>: