Symfony2 vs Django – Models

As promised in my first post, I’m going to be looking at the reasons I chose to go with Django rather than Symfony2. Aside from wanting to learn a new language, there were a few things that jumped out at me when looking into Django.

One of the biggest was the dramatic amount of code necessary to do the same thing in Symfony2. Let’s look at a typical model for a blog. Here’s what it looks like in Django (I’ve added a small utility function via a manager):


Now here’s the same model in Symfony2 along with the utility function:



Wow, that’s a TON of code. I will mention that Symfony2 does offer some tools to help generate this code, which are very helpful. But it feels to me like they’re trying to overcome the shortcomings of the language.

7 thoughts on “Symfony2 vs Django – Models”

  1. I really appreciate your taking the time to document your experiences, but this is a pretty shallow “analysis”, and a pretty weak reason for selecting one framework/language over another. All of that model code can be generated by a few extremely concise lines of YAML, and the benefits of having all of the objected-oriented/ORM code/glue in place automatically (actual overridable getters/setters, and PHPDoc comments, for example) are immense – especially for a large project. I’m an experienced Symfony (mostly v1) dev, and am just getting started with Python/Django…and what you’ve demonstrated here makes me lean more toward Symfony…

    BTW, the link to the speed comparison in your first post in this series is a 404.

    1. When I originally looked at the two frameworks over 2 years ago, my intention was not to do an in-depth, expert-level analysis. So while you could definitely call it ‘shallow’, it’s a good reflection of what could be learned about each framework in just a couple of days with the documentation available at the time (the docs for both frameworks have improved greatly since this was published).

      Had I been an experienced Symfony developer like yourself, I would have known about YAML and the other tricks of the framework, although the YAML still appears to be more verbose than Django and I’m not sure I’m a fan of using a separate language for model definitions.

      In the end, all of these frameworks are very similar – well maintained and documented, have robust feature sets, used by engaged developer communities, and even go so far as to borrow from one another (f.e. Twig based on Jinja / Django). There’s no single correct solution for every project. If you’re a PHP / Symfony developer looking to expand your skill set, try Django. If you need to move quickly, stick with what you already know.

      With that said, after two years of working with Django / Python I have been extremely pleased with the choice. The framework continues to improve under the guidance of the Django Software Foundation and the recent addition of features like Migrations in Django 1.7 have continued to expand an already solid feature set. I’ve also found the available 3rd party libraries to be top notch, both those specifically for Django and those for Python in general. If you’re looking for a new language and framework to learn, I would highly recommend.

  2. Fair enough…Having become intimate over the years with the deep dark corners of Symfony/Doctrine, I guess when I ended up here I was hoping to gain some insight into the under-the-hood differences you had discovered between the way models work across the two frameworks. Maybe the title would be better stated as “Symfony2 vs Django – Specifying Models”.

    Also, I’d encourage you to keep an open mind about specifying models in YAML. For larger projects (say, over 100 models), the ability to manage them in a handful of YAML files organized into functional groups, again, along with all of the free, extremely clean/tight code that you get (which gets kept up to date automatically any time you modify your YAML) is immense – from both getting started and maintenance/troubleshooting perspectives. It’s a very efficient workflow that helps keep things under control.

    I’m just getting back to the project I mentioned in my previous message (and it’s promising to be a pretty large one), and it actually frightens me to think that I might ultimately end up having to manage the model/ORM layer across many dozens of distinct .py files…so I hope I find a better way as I resume the learning curve…but it’s encouraging to hear that you still like Django.

  3. Just like in Symfony, the number of distinct .py files is completely up to you. You can use a single file for everything, break them up into logical groupings or use a distinct file per model. Whatever makes the most sense for your project.

  4. I think you are comparing apples with oranges here. Doctrine follows the Data Mapper pattern, whereas Django models follow the Active Record pattern.

    In Doctrine you have an object that describes your data, but it doesn’t have the final word on what your schema should be. All the details of the database are “hidden” in a mapping file (YAML, or XML, don’t use annotations :P). The advantage of this approach is that you are not coupling your models with an actual db schema, therefore the database itself. Also they are easier to test and can be more performant than their Active Record counterparts. The downside being that they are harder to setup.

    In Active Record your database schema and your models are one. This means they are easy to use and understand. In the other hand they are hard to test, debug, are completely coupled to the schema, database, and BD abstraction layer.

    All of these to say this is not a fair comparison as they are not the same and have different advantages/disadvantages. A fair comparison would have been Doctrine vs SQLAlchemy, or Propel ORM vs DJango ORM.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s