Quantcast
Channel: test.ical.ly » Symfony Live 2010
Viewing all articles
Browse latest Browse all 9

The best feature that Symfony2 will bring us is probably not your first guess

0
0

Symfony2 is coming a long way. For a long time it was a myth and for a probably even longer time it was a thought in Fabiens brain. We learned the first details earlier this year and this week we learned more.

Even now – several months before the first stable release – a ton of features has been presented. The latest being the killer feature Edge Side Includes (ESI) compliant reverse proxy implementation as a PHP cache layer and I’m sure there are more things to come.

But I already do know what will be the best feature!

Fabien would probably start this post with some benchmarks and I’m sure many of you are excited about the figures he presented that promise Symfony2 to be much much faster.

I’m also sure that Fabien would agree with me that a) benchmarks are mostly irrelevant and b) that utmost performance in most cases is not the top problem to solve.

So what is it that I think will be the best feature about Symfony 2?

It’s not the speed and not even the openness towards external sources like the Zend Framework or PHPUnit. And although I love the way the Symfony team more and more involved the community in their ideas and decisions it’s not that yet.

It’s also not the killer feature cache although that’s going to be awesome!

All the other components from CssSelector to sfYaml are great but not a single one of them would make me vote for Symfony. And I really love the event dispatcher!

But we’re getting close there. The event dispatcher has a simple purpose. It’s allows for maximum flexibility while reducing complexity through loose coupling.

And that’s it. Everything in Symfony2 is decoupled. Every component implements only one simple thing, does it good and doesn’t do anything else. Each component can run on its own without any of the others.

This is Separation of Concerns in perfection!

And actually this is also a very common practice in risk management. The bigger something gets the higher the complexity the more risks you have to face that you won’t get finished or that something breaks when you need to change. By dividing a big risk into many small ones you do not reduce the size of a project but you break it down into manageable smaller risks. As simple as that.

I really think that all these independent low risk highly specialised components will be manageable by us all and they will encourage us to separate our concerns as well.

This will hopefully reduce complexity and risks in many PHP projects and therefore as well reduce the costs of IT projects. Symfony2 has a business case there.

To all the core team members and people who contributed in either way: Thanks a lot! This will be a great step forwards for the PHP world.


Viewing all articles
Browse latest Browse all 9

Latest Images

Trending Articles





Latest Images