c# - Is it considered poor DI practice to include your app container within the constructor of a service? -

first, i'm using simple injector think question apply di framework.

when creating services registered application, considered bad practice pass services container service through constructor?

for instance. consider following code.

//iserviceinterface.cs interface iserviceinterface {}  //myservice.cs //all standard using statements here... using simpleinjector;  class myservice : iserviceinterface {     private _container {get; set;}      public myservice(container container)      {         _container = container;          //construct!     } }  //myapp.cs  public contrainer container; ....  //my application bootstrapper method void bootstrap() {     var container = new container();     container.registersingle<iserviceinterface >(() => new myservice(container));     container.verify();     this.container = container; } 

as can see method above, define service class takes simple injector container. when register container, pass container associated app, service.

this seems useful approach when defining service in separate project, may in different namespace, need register new services @ point in application's lifecycle. however, i've not seen done in example , before try this, want makes sure approach correct.

is behavior considered di practice? if not, how obtain applications di container, , register new services needed within service?

update -- additional details

i decided start using dependency injection new project have 2 reasons. one, massive project include 10-12 visual studio projects and, second, many of these projects contain code i've copied , pasted 1 application, on years , modified have been needed. enough of this, it's time write own business-logic framework works our company, need to.

this first, big project seemed place start di , homebrew framework. build , test application one-layer @ time, i'm defining lot of interfaces , "shell" service classes. way, can wire top-level application, , update dependencies projects completed , linked solution.

since such large application, have services, need depend on services... depend further on services.

my thought application should register services need authenticate users , load views. view services should register model views. modelview services should register associated model services, register database connectivity services... sigh, register server-side, synchronization service, register local db connection service , web application service. phew! sound confusing? well, kind of is.

my thought define these classes can take container object, , each service use container either obtain underlying service may exist, or instantiate new 1 if 1 hasn't been created.

for instane, user auth service may cache information through ilocaldb service should shared model services. if register of these services when boot app, app sluggish whole registration pretty gnarly.

i assume there has elegant solution this. missing?

the answer basic question in title has been answered @steven - yes considered bad practice inject container classes. @steven author of simpleinjector , firmly sticks principle - see here

it’s unclear me else asking here’s info may help.

• simpleinjector not recommend registering services throughout applications lifetime , preferred registrations done @ start in composition root. see here

when first type resolved container, container locked further changes. when call 1 of registration methods made after that, container throw exception. container can't unlocked. behavior fixed , can't changed. if must possible register new types after point, unregistered type resolution can used.

• if have objects take time instantiate can inject lazy<> instances instance not instantiated until/unless explicitly referenced in calling path of code. see here

• object lifetime management should deal intricacies of passing in existing instance / instantiating new one. see here

• to keep registration process becoming “gnarly” divide process classes each registers area of solution e.g. dal, commandhandlers, services, etc. these classes should internal composition root responsible bootstrapping entire application , whole bootstrap process called once @ start-up. composition root not need explicit references of assemblies containing of implementations in solution; requires references of services have defined. see here and here