Symfony 2 for PHP developers – Part 1

So, you heard a lot about this web framework called Symfony 2 and everyone is banging on about how fantastic it is, but you don’t understand what the big deal is and now you’re reading this..

To be honest, my introduction to Symfony 2 wasn’t entirely voluntarily, it was forced upon me but I decided to take it and run with it. However, it wasn’t that easy. It took me quite a bit of time to start “thinking in Symfony” and to be honest, after a period of denial, I now “get it”. I now understand what the fuss is about and now I’m writing this in the hope that it might help some other developer out there to get up and running with Symfony 2.

This article is not going to run you through a tutorial. Instead we’re going to talk about philosophy and most importantly about architecture. To “get” Symfony you need to “think in Symfony”. It’s here where most newcomers to the framework start to get into trouble. Usually when you come from another framework to Symfony you’re simply not in the right frame of mind, there are certain things you need to learn and more importantly, things you need to unlearn. I hope that these articles are going to help you bridge the gab between having experience with some other framework and getting started with Symfony 2. My aim for this article, and the articles that follow, is that it will be the glue you need between the past and the future.

When I started with Symfony 2 I actually wasn’t really interested in working with it. I had plenty of experience writing all sorts of things PHP and other languages such as Java and C++ and I had used other PHP web frameworks in the past such as CodeIgniter and Kohana and plenty of WordPress thrown in. MVC here. MVC there. MVC everywhere. An age old design pattern milked dry and over-hyped. I got it. How can this “Symfony” thing be any different, right?

So, I started to read about Symfony, working my way through the documentation, the cookbook and what’s not. Dependency Injection this. Dependency Injection that. Bla bla.. I used what I could and ignored the rest. I had to get stuff done and didn’t have time for all this theoretical mumbo jumbo. So I build stuff and it worked. Actually, to be honest, it didn’t work very well. The problem was obviously that this Symfony thing that was standing in my way, obstructing my goals. The truth is, Symfony was standing in the way. It was standing in the way because I wasn’t using it the way it was supposed to be used. But I ploughed on…

Coincidentally I was looking into the Spring Framework. I love Java, always have and always will. I love the Java ecosystem, the JVM and everything that runs on it. The Spring Framework is very similar to Symfony in the way that at its core it’s all about Dependency Injection. The funny thing was, I “was” interested in learning Spring Framework so it was very easy for me to digest everything about it. It’s only after I worked with Spring Framework and got my head around that, that I had my eureka moment in regards to Symfony.

It’s important to understand that Symfony is more than just a web framework. It’s also a set of components, but with Symfony also comes a workflow and if you come from another PHP web framework then it’s this workflow that is going to make the real difference for you. If you haven’t worked with Composer yet, then well, that’s going to change the way you think about building your projects. To work with Symfony you don’t “have” to use Composer but you’d be a fool if you didn’t.

Composer allows you to manage your dependencies in a way that hasn’t been available to PHP developers until now. OK, PECL and PEAR are cool but Composer is so much better. For one thing, the problem with PEAR libraries is that they are tied to your operating system, not your project. So e.g, if your production server has version 1 of a PEAR library but your development system has version 2 which isn’t compatible then somehow you need to manage all this manually. You either need to upgrade all your projects or only work against the least common denominator. With Composer your dependencies become part of your project, not your operating system. But the best thing about Composer is that anyone who clones your project only has to run a “composer install” command to get all the dependencies they need to run the project. Try doing that with PEAR!

So, here we are. Starting with Symfony 2. In the next article I’m going delve into to the philosophy of Dependency Injection and how this works within the context of Symfony.

This entry was posted in Programming and tagged , . Bookmark the permalink. Both comments and trackbacks are currently closed.