Bernhard, I agree
I was actually thinking about this problem for a while and here is what I
think:
All that's needed for extensions to do IMO is to take some configurable
options
from user, and set them on the DIC.
I think the main problem with those extension is that they are tryingo to
use DIC
as a factory for all of their configurable services.
I think the problem could be fixed by introducing Symfony2 specific factory
classes,
and registering their products (services, they produce) using
'factory-service' and
'factory-method' attributes.
For example, Doctrine connection definitions that are created for DBAL,
could be
removed from extension by introducing ConnectionFactory.
class ConnectionFactory
{
private $options = array();
public function setOptions($connection, array $options);
public function getConnection($connection);
}
then the definitions to be registered in DIC would be very simplistic:
<service id="doctrine.orm.default_connection"
factory-service="connection_factory" factory-method="getConnection">
<argument>default</argument>
</service>
However, I would argue that services with dynamic identifiers should not
even be registered in the container,
and should be accessed through its factories.
Thoughts?
On Tue, Jan 25, 2011 at 9:06 AM, Bernhard Schussek <[email protected]>wrote:
> Hi all,
>
> Jordi pushed me to raise my concerns here. I don't really have a
> solution yet, and maybe I'm the only one who sees these problems, but
> here we go:
>
> I currently see a big problem with the design of the extensions in the
> DI container. As one can see for example in FrameworkExtension and
> SecurityExtension, these classes are by design huge and untestable.
> Especially their untestability is a big issue for me, because a little
> error can shut down your whole application and you won't notice.
>
> Furthermore, AFAIK services set in extension classes can't be
> overridden in other parts of the application. Is this correct? If yes,
> I can't imagine how this will not lead to problems.
>
> As I said, I don't really have a solution. Maybe more abstraction
> could help to reduce the amount of code written in the extension
> classes and make them more testable. Now is our last chance to get
> this right, otherwise we're stuck with this design for the next years.
>
> Please tell me what you think.
>
> Bernhard
> --
> Software Architect & Engineer
> Blog: http://webmozarts.com
> Twitter: http://twitter.com/webmozart
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
*Bulat Shakirzyanov* | Software Alchemist
*a: *about.me/avalanche123
*e:* [email protected]
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
