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:
> 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>();
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.
On 27 май, 16:01, Andre Loker <lo...@gmx.de> wrote:
> 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>();
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?
> 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.
> On 27 май, 16:01, Andre Loker <lo...@gmx.de> wrote: > > 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>();
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?
> > 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.
> > On 27 май, 16:01, Andre Loker <lo...@gmx.de> wrote:
> > > 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>();
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.
On 27 май, 15:13, ashmind <ashm...@gmail.com> wrote:
> 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.
> On 27 май, 15:13, ashmind <ashm...@gmail.com> wrote: > > 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?
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.
>> 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);
>> 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.
>> On 27 май, 15:13, ashmind <ashm...@gmail.com> wrote: >> > 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?
> 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:
> > 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);
> > 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.
> > On 27 май, 15:13, ashmind <ashm...@gmail.com> wrote:
> > > 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?
