Is Child container obsolete?

[Xi Shen]

Hi,

Is Child container still in use in Windsor 4.0? I had some issue using child container, and opened an ticket https://github.com/castleproject/Windsor/issues/323, but nobody replies...I wonder if I am using some obsolete technique that nobody cares.

If child container is obsolete, what is the modern replacement?

Thanks,

David

[Ken Egozi]

So much time since I last touched child containers...

Once resolution went up to the parent container it would not go back to resolve from the child as the direction is one way. 

The right question to be answered is "what is your scenario?" Experience shows that more often than not, a conceptually simpler solution can be had that does not involve child containers. 

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.
Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

[Xi Shen]

Hi Ken,

My scenario is, I want to use DI in my unit test, and I need to override some dependency with mock instance.

I know some people say we should not use DI in unit test. But I think unit test can also be used to verify if the DIs are configured correctly.

I would also like to learn a better way to very DI configuration in real product scenario.

Thanks,

David

On Thu, Sep 7, 2017 at 2:01 PM Ken Egozi <ego...@gmail.com> wrote:

So much time since I last touched child containers...

Once resolution went up to the parent container it would not go back to resolve from the child as the direction is one way. 

The right question to be answered is "what is your scenario?" Experience shows that more often than not, a conceptually simpler solution can be had that does not involve child containers. 

On Sep 6, 2017 8:01 PM, "Xi Shen" <david...@gmail.com> wrote:

Hi,

Is Child container still in use in Windsor 4.0? I had some issue using child container, and opened an ticket https://github.com/castleproject/Windsor/issues/323, but nobody replies...I wonder if I am using some obsolete technique that nobody cares.

If child container is obsolete, what is the modern replacement?

Thanks,

David

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Castle Project Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/castle-project-users/RH28ZoTfwxQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.

[Ken Egozi]

You can use a IHandlerSelector to override specific registrations (see http://kozmic.net/2009/12/07/overriding-generic-componentrsquos-resolution-in-castle-windsor/ for an example of using a selector, yours would be different of course)

As a side comment - testing the configuration is a novel idea. I am not sure that a unit test is were you would best test something that is an integration by nature, especially when you are mucking about with the thing under test itself (the container registry). Leave that to integration or system testing.

Ken Egozi.
http://kenegozi.com/

On Thu, Sep 7, 2017 at 1:32 AM, Xi Shen <david...@gmail.com> wrote:

Hi Ken,

My scenario is, I want to use DI in my unit test, and I need to override some dependency with mock instance.

I know some people say we should not use DI in unit test. But I think unit test can also be used to verify if the DIs are configured correctly.

I would also like to learn a better way to very DI configuration in real product scenario.

Thanks,

David

On Thu, Sep 7, 2017 at 2:01 PM Ken Egozi <ego...@gmail.com> wrote:

So much time since I last touched child containers...

Once resolution went up to the parent container it would not go back to resolve from the child as the direction is one way. 

The right question to be answered is "what is your scenario?" Experience shows that more often than not, a conceptually simpler solution can be had that does not involve child containers. 

On Sep 6, 2017 8:01 PM, "Xi Shen" <david...@gmail.com> wrote:

Hi,

Is Child container still in use in Windsor 4.0? I had some issue using child container, and opened an ticket https://github.com/castleproject/Windsor/issues/323, but nobody replies...I wonder if I am using some obsolete technique that nobody cares.

If child container is obsolete, what is the modern replacement?

Thanks,

David

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "Castle Project Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/castle-project-users/RH28ZoTfwxQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to castle-project-users+unsub...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.

[hammett]

The parent/child containers were never properly designed. The thing just fell into place as is. It's really not recommended, unless you have deep understanding on the inner workings of windsor. Ken's suggestions are more friendly for what you're trying to accomplish. 

On Thu, Sep 7, 2017 at 4:32 AM, Xi Shen <david...@gmail.com> wrote:

Hi Ken,

My scenario is, I want to use DI in my unit test, and I need to override some dependency with mock instance.

I know some people say we should not use DI in unit test. But I think unit test can also be used to verify if the DIs are configured correctly.

I would also like to learn a better way to very DI configuration in real product scenario.

Thanks,

David

On Thu, Sep 7, 2017 at 2:01 PM Ken Egozi <ego...@gmail.com> wrote:

So much time since I last touched child containers...

Once resolution went up to the parent container it would not go back to resolve from the child as the direction is one way. 

The right question to be answered is "what is your scenario?" Experience shows that more often than not, a conceptually simpler solution can be had that does not involve child containers. 

On Sep 6, 2017 8:01 PM, "Xi Shen" <david...@gmail.com> wrote:

Hi,

Is Child container still in use in Windsor 4.0? I had some issue using child container, and opened an ticket https://github.com/castleproject/Windsor/issues/323, but nobody replies...I wonder if I am using some obsolete technique that nobody cares.

If child container is obsolete, what is the modern replacement?

Thanks,

David

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "Castle Project Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/castle-project-users/RH28ZoTfwxQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to castle-project-users+unsub...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,
hammett
http://www.d-collab.com/
http://www.hammettblog.com/

[Sunny]

Hi,

so if I understand correctly, you would like to:

1. test if your registrations, etc - are OK

2. use the existing container to get classes to tes, so it essential auto-wires-up the dependencies, but you replace them with mocks when/if you need it

If the above is correct, I had solved it by:

1. create a separate test, which uses Diagnostics to inspect the registrations, if all are ok, and if there are missing registrations

2. I have created a small helper base test class, which auto-registers mocks for each dependency a class needs (using windsor underneath to put mocks as dependencies)

Lmk if I'm correct in my assumptions and I'll make the above code public.

On Thu, Sep 7, 2017 at 3:32 AM, Xi Shen <david...@gmail.com> wrote:

Hi Ken,

My scenario is, I want to use DI in my unit test, and I need to override some dependency with mock instance.

I know some people say we should not use DI in unit test. But I think unit test can also be used to verify if the DIs are configured correctly.

I would also like to learn a better way to very DI configuration in real product scenario.

Thanks,

David

On Thu, Sep 7, 2017 at 2:01 PM Ken Egozi <ego...@gmail.com> wrote:

So much time since I last touched child containers...

Once resolution went up to the parent container it would not go back to resolve from the child as the direction is one way. 

The right question to be answered is "what is your scenario?" Experience shows that more often than not, a conceptually simpler solution can be had that does not involve child containers. 

On Sep 6, 2017 8:01 PM, "Xi Shen" <david...@gmail.com> wrote:

Hi,

Is Child container still in use in Windsor 4.0? I had some issue using child container, and opened an ticket https://github.com/castleproject/Windsor/issues/323, but nobody replies...I wonder if I am using some obsolete technique that nobody cares.

If child container is obsolete, what is the modern replacement?

Thanks,

David

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.

To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "Castle Project Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/castle-project-users/RH28ZoTfwxQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to castle-project-users+unsub...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsub...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Svetoslav Milenov (Sunny)

Artificial Intelligence is no match for natural stupidity.

[Xi Shen]

Hi Sunny,

I think my current approach is similar to yours. I do the DI verification in separated cases, then inject the mocks in other cases.

I wish Windsor has what Autofac has, the last registration wins policy. So we can use the same DI configuration everywhere, and only need to make a small amount of overriding when needed.

Regards,

David

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "Castle Project Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/castle-project-users/RH28ZoTfwxQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.

Visit this group at https://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Svetoslav Milenov (Sunny)

Artificial Intelligence is no match for natural stupidity.

--

You received this message because you are subscribed to a topic in the Google Groups "Castle Project Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/castle-project-users/RH28ZoTfwxQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.

[Matt Davis]

Hi Ken,

I just stumbled on this trying to achieve something similar to Xi. Long have gone the days where I do any specific unit testing instead opting for outside in bdd style testing on my api's and only using smaller unit tests to flesh out the more complicated components. With that my tests spin up my owin or now days dotnet core api's using the TestServer components that allow you to test your services in memory and not having to host them on an actual port.

In most cases my start up classes allow for a action to be injected into either the owin or the dotnet startup class that wires up any dependency overrides needed for the test, this action is run on the container before the concrete components are wired up and this works fine as long as my test overrides are marked as default and given a unique name.

Example:

class StartUp
{
 public StartUp(): this(c =>{}) {}
 public StartUp(Axtion<IWindsorContainer> customWireup) {}
 public void Configuration(IAppBuilder app)
 {
  ...
  var container = new WindsorContainer();

  customWireup(container);

  container.Install(FromAssembly.This());
  ...

 }
}

This has been working great however where I am now testing api calls that call other API's I use the above TestServer components to create a fake api endpoint. I don't know how well you know the Microsoft TestServer components but these expose a HttpClient which is wired directly into the pipeline. I then want to inject this into my IoC wireup instead of the real HttpClient that would normally be used. Currently I can do this using the above by my IoC wire up and the test wire up is getting a little messy. I wanted to do the following but couldn't because the names where not unique so I thought using a child container would help but alas it does not pick up the child registration only the parent registration.

\\Installer

.Register(Component.For<SomeClient>().DependsOn(Dependency.OnComponent(typeof(HttpClient), "someHttpClient")))

.Register(Component.For<HttpClient>().UsingFactoryMethod((kernal, model) =>

{

 var config = kernal.Resolve<ISomeConfig>();

 return new HttpClient { BaseAddress = config.Endpoint };

}).Named("someHttpClient").LifestyleSingleton())

\\Fixture

c.Register(Component.For<HttpClient>()
 .UsingFactoryMethod((kernal, model) => fakeServer.HttpClient)
  .Named("someHttpClient").LifestyleTransient());

I had a quick look at the IHandlerSelector but this looks like it is going to create a lot of cruft when setting up each test. Has there been a decision on the child containers? I am not sold on using child containers but I am looking for anything that would simplify both the start up IoC wire up where my tests impose as little impact on the code as possible and simplify providing test specific component implementations.

Thanks,

Matt