Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The <code>ServiceManager</code> is by default injected within any ZF2 controller, as it extends the <code>AbstractController</code> implementing the <code>ServiceLocatorAwareInterface</code> interface.</p> <p>The second approach has a form of "<a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself" rel="noreferrer">redundancy</a>" because, besides having already access to a <code>ServiceManager</code> instance, whenever you need to share your service among your controllers, you need to configure for each one of them the injection mechanism. As your controllers have already a dependency vis-à-vis the ServiceManager, It would make more sense to use the first approach and register your Domain related Services to the <code>ServiceManager</code>, centralizing thus the access to the Service layer.</p> <blockquote> <p><sub>Note: The following part of the answer may go beyond the scope of the question, but it aims to provide the "hidden" background of the original one. </sub></p> </blockquote> <p>Let's assume we're building a complex system, within which low-coupling, re-usability &amp; test-ability are promoted. Our system is multi-layered and we built everything until the service layer. Note that until now we did not consider yet the "MVC" web layer or even opt for a given framework.</p> <p>Within our Service Layer (I'll consider this layer as it is the one mentioned in the question), we assume that we adopted the <a href="https://www.youtube.com/watch?v=wEhu57pih5w" rel="noreferrer">principle</a> of separation between the Business Logic and the Object Graph construction (or dependency resolution). So we have probably a couple of complex services that are constructed through factories.</p> <p>Now that our service layer is built, we decide to "plug" it above ZF2. Naturally, Our services should be accessible from the controllers, as your question illustrated it, we have more than a way for doing it. However, we want to avoid redundancy and leverage what we've already built. Let's assume the following factory :</p> <pre><code>//The following class is a part of our Service layer public class ComplexServiceFactory{ private dependencyA; private dependencyB; public function buildComplexService() { $service = new ComplexService(); $service-&gt;setDependencyA($this-&gt;dependecyA); $service-&gt;setDependencyB($this-&gt;dependecyB); return $service; } } </code></pre> <p>What we'll do now is just to adjust (actually extend) our factory so that it becomes usable by the <code>ServiceManager</code> logic. This class can be considered as part of the mechanism used to "plug" our system to ZF2 (It's actually an <a href="http://en.wikipedia.org/wiki/Adapter_pattern" rel="noreferrer">Adapter</a>)</p> <pre><code>public class SMComplexServiceFactory extends ComplexServiceFactory implements Zend\ServiceManager\FactoryInterface { public function createService(ServiceLocatorInterface $sm) { $this-&gt;setDependencyA($sm-&gt;get('dependecyA')); $this-&gt;setDependencyB($sm-&gt;get('dependecyB')); return parent::buildComplexService; } } </code></pre> <p>By doing so, we're not bringing up the object graph construction to the MVC layer <b>(otherwise it would be a <a href="http://en.wikipedia.org/wiki/Separation_of_concerns" rel="noreferrer">Separation of Concerns</a> violation and an unnecessary cross-layer coupling)</b>. The Service Manager + our "Adapted" factories classes are in some sense our dependency resolution mechanism. The fact is that our System is still portable, we could for example opt for another system (another framework) and have a low dependency vis-à-vis the MVC platform. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload