2009/10/31 Pádraic Brady <padraic.br...@yahoo.com>:
> I think Matthew is pointing out that there have always been doubts about
> utilising a DI container in light weight languages like PHP, Python, and
> Ruby. In essence, it's remarkably hard to create a valid use case for a DI
> container. You can create any number of artificial examples, but the light
> weightedness of PHP, it's tolerance for loose coupling, and the minimal code
> it generates (all reasons why we use it) make using DI overkill - probably
> in 95% or more of the common uses for PHP.
>
> There are some interesting case studies in Ruby if you go looking where
> individuals have experiemented in writing a DI container/framework for Ruby.
> Ruby has several Di containers/frameworks - nearly all them are classified
> as dormant. Ruby has one very neat thing over PHP - you can overload object
> instantiation.
>
> This is not to say a DI container is useless or meaningless, but the
> classical concept of a DI container from Java or C# is only marginally
> useful in PHP. In most respects all you really need is a little substitution
> and light mapping. If that's the goal of any future DI work in ZF, then
> please, fire on all cylinders. Whether that would qualify as a DI container
> or not is anyone's guess ;). Once you start accumulating more features, more
> complex mapping, and more classical injection methods - then it will bury
> itself into oblivion as an overarchitected mess 99% of PHP developers just
> do not need.

Thanks for the informative debate, I suppose it breaks down to how
much you use something like a DI Container in an application, like
most things in life :) Most of the testability problems can be
overcome by using manual injection / lazy injection and things like
the universal construct anyway....

Sorry to keep this thread going for so long I went a bit off topic :)

>
> My 2c :)
>
> Paddy
>
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>
>
> ________________________________
> From: keith Pope <mute.p...@googlemail.com>
> To: fw-general@lists.zend.com
> Sent: Fri, October 30, 2009 7:19:25 PM
> Subject: Re: [fw-general] Discontinuing Zend Entity in favour of Doctrine
> integration
>
> 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....
>
>>
>> As for criteria objects, we've just approved another of Ben's
>> components, some extensions to Zend_Db_Expr. One aspect I particularly
>> like with it is that, combined with Zend_Db_Select, we are getting to a
>> point where we have an almost complete criteria object for select
>> operations. This could certainly be adapted for use with DDD fairly
>> easily. Regarding repositories, Zend_Application_Bootstrap actually
>> already acts as one in many ways -- though we may do more with this
>> and/or service locators for 2.0.
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead            | matt...@zend.com
>> Zend Framework          | http://framework.zend.com/
>>
>
>
>
> --
> ------------
> http://www.thepopeisdead.com
>



-- 
------------
http://www.thepopeisdead.com

Reply via email to