Decoupling the ZF glue layer

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Decoupling the ZF glue layer

Gregory
If the service locator and DI are supporting aliases, it should be possible to create another 'thin' layer. The bits of ZF glue could be put into a Zend/Framework sub directory, e.g Zend/Framework/Mvc/Application.php.

I think the primary targets are factories and any other classes or code which would benefit from residing at a layer above the various components it uses.

The Zend/Framework directory would allow for physical files which can either override other (parent) library files, or simply exist in order to provide a use able framework/application interface, e.g Zend/Framework/Mvc/Service/ServiceListenerFactory.php otherwise aliases can be used to point directly to the other library components.

For example, all factories requiring the ServiceLocator could reside within the Zend/Framework sub directory, and the existing component factories would no longer use the ServiceLocator but instead have their dependencies explicitly passed to them, e.g $config instead of $service->getConfig();

An alternative to the Zend/Framework subdirectory would be to create another vendor lib completely, but that might make the setup a little more complicated - I'm not sure if apigility might be able to come into play here.

The point is that there is some form of namespaced layer that assists in more clearly distinguishing and decoupling code that exists in order to orchestrate the underlying components into a coherent API (i.e. easy to use Framework)?