-- keith Pope <mute.p...@googlemail.com> wrote (on Friday, 30 October 2009, 07:19 PM +0000): > 2009/10/30 Matthew Weier O'Phinney <matt...@zend.com>: > > -- keith Pope <mute.p...@googlemail.com> wrote > > (on Friday, 30 October 2009, 04:43 PM +0000): > >> 2009/10/30 Matthew Weier O'Phinney <matt...@zend.com>: > >> > -- keith Pope <mute.p...@googlemail.com> wrote > >> > (on Friday, 30 October 2009, 04:02 PM +0000): > >> > > 2009/10/30 Ralph Schindler <ralph.schind...@zend.com> : > >> > > Also will we be deprecating Zend_Db as if we have tight Doctrine > >> > > integration is there any reason to keep Zend_Db? > >> > > >> > There are plenty of reasons to keep Zend_Db. Not everyone will be using > >> > Doctrine, and for many one-off types of applications (single tables, or > >> > multiple tables with no relations, etc.), having Zend_Db around will > >> > continue to be essential. Additionally, one aspect I'd like to explore > >> > with the Doctrine folks is potentially allowing Zend_Db adapters as > >> > Doctrine RDBMS adapters; this would provide some very interesting > >> > integration points. > >> > >> Sounds interesting I look forward to seeing this initiative develop > >> further, I would be happy to help in any way I can :) > >> > >> Once we have the integration especially with doctrine 2 would there be > >> any further plans to look at things like dependency injection, > >> criteria objects and repositories or any other DDD tools? To me having > >> a full suite of tools like this would be a great long term goal? > > > > DI is something we're already planning for -- you'll note the "unified > > constructor" pattern in all new components. Whether or not we'll have a > > DI _container_ is another question; I'm not entirely convinced DI > > containers have a good place in stateless applications, but I'll let > > Ralph talk more to that point. :) > > That is an interesting point, I dont quite understand how state > affects object dependencies or is the container an unnecessary > overhead when you are working in a limited state environment? > Something I may have to ponder....
There are two things: * Depending on the architecture of the DI container, you may end up with many objects instantiated which are never used -- leading to overhead. DI containers evolved in large part in Java, where you want to preload everything, as eventually everything will be loaded anyways. This is not true of PHP applications, where often what is loaded is determined by the execution path. * Complexity of setup. When you have a DI container, you often have large, complicated dependency setups that are difficult to understand unless you understand the entire application architecture. This can make learning the framework and/or individual applications much more difficult -- as well as determining where and when in the configuration to make changes. For examples, look at tomcat or any atlassian tool (not to dis the tools, but they all exhibit very complex dependency setups). -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/
