On Fri, Jan 10, 2014 at 12:41 PM, Matthew Weier O'Phinney <matt...@zend.com>wrote:
> The ServiceManager is far easier to configure, and much more > performant (though, as with just about any generalized component, > could be even better). > > If you are looking for an IoC container to manage DI for your various > services/instances, I'd recommend Zend\ServiceManager instead of > Zend\Di. > I was looking into that, but ran into a configuration snafu when I hit the DB component: I couldn't figure out a way to Lazy load PDO (requires a DSN) when the DSN is stored within the same file as the SM configuration. And SM Configuration doesn't have a built-in "config" pass. All that stuff is injected via Zend MVC, which I'm not using. DI doesn't really solve this either, but using a Proxy class could work ... maybe. My application is very simple: a single php tracking script. Reads in visits, deciphers their cookies, and makes a call to a DB or Web Service back end depending on parameters from their cookie. The basic requirements are: - Speed - Parsing and managing incoming and outgoing cookies. - Ability to set content-type headers to either json or gif. - Log to directly to DB or Web Services (or neither), depending on cookie parameters. zend-http resolves a number of these: it gives me PhpEnv.\Request and Response, as well as Http\Client for WS. My plan for DB was PDO directly (using pdo_cassandra). Now, I want this to be easily swappable for testability, and that's where I ran into the trouble. Naturally, you'd think DI and a DiC; however, DiC is notorious for not being speedy, unless configured (thus my config question). In addition, it's not a lazy loader, something I was toying with the idea of Proxy class for. ServiceManager would resolve the swapability of RequestInterface and ResponseInterface. But, I fell when it came to configuring for lazy loading. PDO requires a DSN, which is stored within the same config as SM values. And, I can't load PDO until I know "this request" is to be logged to the DB. WS is slightly less tricky: it's not as overhead dependent, and can be instantiated with no impact, and URL set at a later time. --- Philip g...@gpcentre.net http://www.gpcentre.net/
