Why should UsingFactory be avoided and what improves on it?

My application has low level general-purpose services that depend on SqlConnection and DbConnection and a high level UserAccountService with a CreateConnection method. (UserAccountService manages SecureString credentials.)

It took a long time searching through the documentation to figure out a way to make this work. The low-level services cannot take a dependency on UserAccountService and they also cannot take a dependency on a typed factory. They must be injected with SqlConnection and DbConnection.

I finally found the ideal configuration method for this. This is precise and minimalist and I could not have asked for a better config function:

Component.For<DbConnection, SqlConnection>()
    .UsingFactory((UserAccountService userAccountService) => userAccountService.CreateConnection())
    .LifestyleTransient()

My concern is that the documentation also states that UsingFactory should be avoided and is going away in future versions.

Why is this? First, what’s the downside to UsingFactory that I should be aware of? Second, is there a paradigm that satisfies the criteria I have in an even more precise and minimalist fashion?

[jnm2]

@dalefrancis88 Those options are not feasible like I said because I can’t modify those lower-level services to accept a UserAccountService or an IConnectionFactory because they are in a different codebase. I do actually need to inject a straight-up SqlConnection.

@IanYates that’s good to know. I think that should be specifically documented here and everywhere you can explicitly Resolve without pairing with an explicit Release. That’s an important rule of thumb to understand and know the boundaries of.

So what you’re saying is that it behaves exactly as I would hope- the factory lives as long as the generated component. So far so good. So to deal with my remaining concerns:

I love this. It feels good and is immediately familiar, easy and comprehensible because it is in actuality dependency injection. It purely and almost declaratively defines the relationship between SqlConnection and UserAccountService:

Component.For<DbConnection, SqlConnection>()
    .UsingFactory((UserAccountService userAccountService) => userAccountService.CreateConnection())
    .LifestyleTransient()

This is strongly distasteful because it is in actuality service location. I want to follow the 3 R’s pattern; I want to write Resolve one time in my entire codebase. Not here. On top of that, it’s just more clunky to type and read:

Component.For<DbConnection, SqlConnection>()
    .UsingFactoryMethod(kernel => kernel.Resolve<UserAccountService>().CreateConnection())
    .LifestyleTransient()

So why avoid UsingFactory? Why is UsingFactory not in fact better recommended, since IKernel could be injected with UsingFactory too if you need it for some other reason?

[ghost]

@mario-d-s Windsor Factories* are on my hit list as soon as I am done with the ASP.NET stuff. They most definitely need a complete re-write as far as I am concerned. The lifestyle violations for factories alone are stacking up on this issue tracker. They are also incredibly hard to solve.