c# - Inject Using Formal Parameter Name -

this question uses unity syntax, applies ioc containers.

if have constructor takes dozen dependencies, no big deal:

container.registertype<icustomerservice, customerservice>(); 

later might need 1 of constructor parameters filled named instance. unfortunately api approach becomes ugly:

container.registertype<icustomerservice, customerservice>(new injectionconstructor(     typeof(icustomerrepository),     typeof(ientitymapper),     typeof(icontext),     typeof(ionboardingvalidator),     typeof(icustomervalidator),     typeof(icustomerverifier),      typeof(icustomerhelper),      new resolvedparameter<httpclient>("producer"),      typeof(ilog))); 

i avoid kind of ugly verbosity placing [dependency("producer")] annotation on constructor parameter itself, unfortunately business assembly take dependency on unity libraries, trying avoid.

what perfect if there way tell unity (or autofac, windsor, simplerinjector, structuremap, etcetera) use formal parameter name declared in constructor "as if" represented named instance inject. if formal parameter name not match named binding, assumes use default binding.

something this:

container.registertype<icustomerservice, customerservice>(new injectionnamehandler()); 

perhaps serve same purpose property injection well.

the above hypothetical directive saves me effort of having specify every parameter of constructor, adjust resolution of single parameter.

granted assumes longest constructor in concrete type 1 i'm interested in, precisely when helpful!

is there way in unity 2? unity 3? or other ioc container?

if have constructor takes dozen dependencies, no big deal

as matter of fact, big deal. components many dependencies tend violate single responsibility principle (srp). srp violations lead code hard test , difficult maintain.

if refactor code multiple more concise classes, problem might not go away completely, less of problem.

i think code great example of violating single responsibility principle. problem starts name of class: customerservice. 'service' postfix smells violation of single responsibility principle, open/close principle (ocp) , interface segregation principle (isp) me. violate srp, since class tend hold many use cases related customers. grouping stuff single entity doesn't make single responsibility. violating ocp, because every time new customer-related use case added, have change class , interface. icustomerservice interface violates isp, because have many methods, while consumers of interface need 1 or two, never of them.

besides this, customerservices class depends on ilog , icustomervalidator services. these seem cross-cutting concerns , main class should not concerned cross-cutting concerns. should apply cross-cutting concerns using aspect-oriented programming (aop) techniques such interception or (preferably) decoration.

this inevitably lead design described here , here, each use case gets own class, , use cases placed behind same generic one-member-abstraction.

later might need 1 of constructor parameters filled named instance

although not hard rule, experience it’s not common component have both configuration values , many dependencies @ same time. here again might violating srp here, because might want abstract producer parameter away.

especially when httpclient talking .net framework type, such system.net.http.httpclient. in case violating dependency inversion principle (dip) because not depending on concrete type instead of abstraction, framework component, should application should define abstractions needs.

so instead of injecting httpclient, inject service tailored application needs , follows solid principles. can never framework component , not framework supplied abstraction, because such abstraction still violate dip , isp.