Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p><sub>If your views never know which service has been used by controller to alter the state of model layer, then your best approach would be instead implement classical MVC (or close to it) with current view observing the model. In that case each used service would inform the view, when it has been acted upon by controller. <strong>If that's the case, then content below does not apply.</strong></sub></p> </blockquote> <h3>The bad idea ..</h3> <p>The views and controllers should share the factory, which is responsible for initializing the services. this means that if you controller has used a particular service, then you can add an ability to query this factory about services that it has initialized already.</p> <pre><code>if ( $this-&gt;serviceFactory-&gt;hasCached('recongnition') ) </code></pre> <p><strong>But</strong> that should not be necessary and IMHO, that would be a really harmful thing to do. You would be forcing the factory to become a vital part of UI logic.</p> <blockquote> <p><sub><strong>Note:</strong> the factory in this case enforces, that each service is create only once, without dependence on global state. </sub></p> </blockquote> <h3>Different approach/perspective</h3> <p>For some reason, you start out with a premise, that every view has to be omniscient. That's what causing you current confusion.</p> <p>Instead of knowing everything about everything the two fictional services: </p> <ul> <li><code>Accounting</code>: for dealing with invoices</li> <li><code>Library</code>: for managing documents </li> </ul> <p>When you are looking at the page, which list the current document, why would the view care, that there is an error state in <code>Accounting</code> service? How would you actually achieve that error state?</p> <p>Would an error state in any of those services affect how the "login page" looks like?</p> <p>So. The bottom line here is this: even if controller does something, which causes an error state somewhere in the model layer, the view should only know about it, only <strong>if the view needs that particular service</strong>.</p> <blockquote> <p><sub><strong>Note:</strong><br>Of course since in web applications the views and controllers tend to form pairs (if there is controller for handling "Document List", then there probably will also be a corresponding view), it will be and extremely rare occasion, when controller utilizes some service of which the current view is not aware of ... I actually cannot think of a use-case for such occurrence.</sub></p> </blockquote> <h3>P.S.</h3> <p>Actually the state of model layer is not held in the services themselves, but in the domain objects which they manipulate. </p> <p>If you use a shared factory, which can make sure that each service is initialized only once, then the service, that view uses, will be the same. It also means, that the domain objects, with which service worked, can still be there (depends on your implementation, of course).</p> <p>For example, if you try to create user account, with an email that already exists, the domain object for representing the account details will acquire an error state, when storage abstraction gets an exception about violating <code>UNIQUE</code> constraint. To show a good "registration failed" page, the service will need that domain object with both its data and its error state.</p> <p><kbd>I hope it helps</kbd></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