dependency injection - PHP DI/IoC Container configuration for every object in Application or? -

i have 1 question: need configure di/ioc container every object in application or configure factories ?

now have this:

'servicefactory' => function() use ($container) {     return new \application\core\factory\servicefactory($container->get('entityfactory'), $container->get('repositoryfactory'), $container->get('cache'), $container->get('file'), $container->get('image')); },  'repositoryfactory' => function() use ($container) {     return new \application\core\factory\repositoryfactory($container->get('database'), $container->get('querybuilder'), $container->get('mapper'), $container->get('language')); },  'entityfactory' => function() use ($container) {     return new \application\core\factory\entityfactory($container->get('language')); }, 

but then, application loads unnecessary objects other objects not needed.

example: in blogservice not use file class or image class. in thumbnailservice do, don't use entity or repository inside it.

so, need import lazy loading inside di/ioc container or need write every entity/repository/service/controller connection this:

'blogcontroller' => function() use ($container) {     return new \application\controller\blogcontroller($container->get('blogservice')); },  'blogservice' => function() use ($container) {     return new \application\service\blogservice($container->get('blog'), $container->get('categoryentity'), $container->get('blogrepository'), $container->get('cache')); },  'blogrepository' => function() use ($container) {     return new \application\model\repository\blogrepository($container->get('database'), $container->get('querybuilder'), $container->get('mapper'), $container->get('language')); },  'blog' => function() use ($container) {     return new \application\model\entity\blog($container->get('language')); },  'thumbnailservice' => function() use ($container) {     return new \application\service\thumbnailservice($container->get('image'), $container->get('file')); }, 

but way writing 50-100 entities, repositories, services , controllers, maybe over-optimization ?

any suggestions ?

no, need register types can vary i.e concrete implementations of abstraction. if aren't using abstractions di container isn't useful.

the di container should allow register types using conventions e.g register classes name needing in "service" services. way define 'rules' , registration done automatically regardless how many services have in app. @ least how things in .net , writing manually registration of 50-100 classes code smell.

update

it should this

 interface isomeservice {}   class myservice implements isomeservice { }   class otherservice  {      private $svc;      function __construct(isomeservice $svc)      {          $this->svc=$svc;      }        function dostuff()       {           //do stuff using  $this->svc       }  }   //dicontainer  //here you should register things (i don't know container php, i'll write i'm using in c#, you'll idea)              container.registertypes(myassembly)             .where(type=>type.name.endswith("service"))             .asself()             .asimplementedinterfaces(); 

the code above tells container scan classes name ending in "service" (my convention) , automatically register them used when either specific type requested or implementation of interfaces implemented type.

in our example, means when instance of otherservice requested container, container knows use myservice type concrete type isomeservice . container looks constructor detect dependencies object needs.

in order use di container, (mvc) framework should aware of it, because isn't meant used directly app. there cases service locator pattern valid, the framework should use container create instances of services need.

you configure container when app bootstraps (as part or integrated mvc framework) , that's it. next, define interfaces , classes (services,repositories,event handlers etc). thing should come conventions allow container auto register classes based on them (such naming services "service").

di containers first appeared in statically typed languages (java, c#) makes more sense used, compared dynamic language aren't constrained type (that's why i'm using type hinting in php). they're still useful there're bit harder understand.