How beautiful Expression Language definitions are, right? I mean, inserting that complex expressions in a Dependency Injection configuration file is so nice and fast if you need to inject the result of a method in a service (one of the multiple examples we can see)
Let’s see a simple example of how we use this library.
1 2 3 4 5 6 7 8 9 10
This is not a bad idea, really, but because we are engineers and we should have as much information as possible in order to be able to choose between the best option, always, I will show you another way of defining this piece of code.
Let’s do that!
Remember the Factory pattern in Symfony2 post I wrote some time ago? I talked about how this pattern can be implemented in your Symfony projects.
Well, just for your information, most of your Expression Language definitions can be nicely done using Factories.
Let’s reproduce the same example using factories.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Take a look and realise that we’ve removed a package dependency from your
project, as you don’t need
symfony/expression-language anymore, and your DIC
definition will be easily exportable to another format if someday is needed.
Is Expression Language a bad choice? Well, only you should be able to know if using this library is a good choice or not, because only you know your needs and your resources, but every time you add a new Expression Language line, just ask yourself…
Can I use simple DI definitions here? Is the only way I can do that?