Understanding the structure of symfony

The backstory

There you are in your new office, recently hired, when your boss suddenly barges in. Mr. Gnarf, a grumpy old man, wants to destroy the largest and hippest social network there is: MySpace. You're about to open your mouth but you realize he seems rather stubborn and he's holding onto his cane rather tightly, so you slightly nod.

He slams down a pile of paper on your desk; Apparently, the specs for your first web application which he goes on to say it will be called letsGetTogethr. Named so because he loves the pretty pictures on Flickr.

It's going to be like any other social network but "better". For now, though, he charges you with implementing the profile page. You ask, "Is that it?". Well, things can't proceed further without millions of dollars of investment according to your boss. He assures you the beta label will cover all bases in the meantime.

"Oh, and it should be done using Symfony. I read I should use it somewhere in a forum ...", he trails off as he walks away.

Your stomach begins to tremble since you never even heard of Symfony. It just seems complicated. Fortunately, you remember this female programmer on the staff from your interview. Possibly the reason you joined? No time for that. After combing your hair, you find her. After introductions, Vanessa was her name, she agrees to help but, seeing she was busy, decided on a quick rundown for now.

The BIG picture - Keeping your files in order

One thing Symfony attempts to do is keep related PHP files together under one directory if they primarily deal with a certain functionality.

In letsGetTogethr, all profile logic (i.e dealing with the display of the user profile) can be placed together in a 'profile', or whatever you call it, folder and code implementing the chat feature in another. These folders, in turn, are housed under the modules directory. As your application grows, your files will mainatin a certain level of structure and organization, which especially helps when working with other developers. It may require getting used to but it's for the best.

A closer look - Keeping your code in order

We can and do go even further than mentioned above. Maybe you were wondering what was happening in the 'profile' directory since folder structure was lightly touched. Doing so means going to the heart of this PHP framework.

Now, while you may be accustomed mixing application with presentation logic, Symfony does not go about it this way as it tries to separate your code into three main parts:

1. MODEL - How the data is accessed and manipulated

   

   As you must know, on the Internet the majority of data is stored on databases with the likes of MySQL and PostgreSQL. For letsGetTogethr, you can create a user table to hold all personal information such as name, birthday, telephone, address, etc. All of which will be on display in the profile.

   What you may not know, is in order to access any data, you don't use your standard PHP/SQL queries but rather through PHP Objects. Pardon me? Yes, we are talking about the Object Oriented way but not in the way you may think. You see, in Symfony, through Propel, PHP classes are created to represent all your tables and they become the bridge which allows interaction with your database.

   

   In this case, when you need to access a user's name from the user table, you do so by: $myUser->getName(). Or maybe you need their address? No problem. $myUser->getAddress(). Bet you a dollar you can't guess how we access a user's telephone.

   On second thought, never mind.

   Furthermore, because you are no longer dealing directly with databases but instead with Objects for data access, you can add new functionality to these Objects. Let us say you need to display their age but currently only storing their birthdate, you can add a new method to the User object called getAge() which calculates the age simply from the birthday field. There. It's defined. Now whenever you need it, you can simply call the function as though it was part of the table like so: $myUser->getAge() And where can I make these changes you ask? It's all in the lib/model folder

2. VIEW - What will the people see?

   

   The view? Hmmm ... I wonder what this is all about? Like you couldn't guess. This section is composed solely of PHP template files dealing with presentation. That's right, what you wish the user to look at. HTML and PHP intermingle all they want right here except, unlike the Model layer, these PHP files are not located in a single folder but rather are scattered. Don't worry, there's order to it. Each module you create, such as 'profile' or 'chat', will have it's own 'templates' directory. In this way, every module takes care of how it will be rendered in HTML and whatnot. If you have a designer, they'll be most comfortable here where they can work their magic.

    

3. CONTROLLER - The brains of the operations

   

   In the same way that each module has a templates directory, so too for the Controller layer except it's named the 'actions' folder. This is where all the action is at ... I mean ... where the application logic resides. So, when somebody visits letsGetTogethr.com/profile?id=77, the PHP files under the action's folder (which is part of the profile module, remember?) will know what to do. Oh, you know the deal, check if the user is logged in, if that profile even exists, call the monkeys from outerspace, etc. Basically, they are the puppet masters in their respective module, controlling the other layers to do what it wants, and of course, they do your bidding.

That's what you call a good design pattern

This separation of code make up what is called the MVC software design pattern. While other aspects of the Symfony framework were left out such as generators, routing or you might be wondering what the validate folder, now seriously, is for, this simplified overview will more than help you out.

Perhaps now you'll be able to navigate quicker in Symfony and, just maybe, understand Wikipedia's definition of MVC and its application to this framework.

Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

Wikipedia - MVC

Next time

"Now, run along before Mr. Gnarf finds us wasting company time. I'll explain more later", Vanessa says as she pushes you out of her office

This guest post written by Steven Villaverde

Photo Credits: First image by Chocolate Vipul Geek and the rest by Steven Villaverde