ASP.NET MVC Compared to Django

The MVC pattern is widely used in web development today. Regardless of whether you develop in C#, PHP, Python, Java, JavaScript, or Ruby, you won’t have any trouble finding a popular MVC pattern for your language of choice.

Being primarily a C# developer, I’ve been using ASP.NET MVC since version 1. It’s a great framework. It can be very good at getting a project off the ground quickly, especially when coupled with a good ORM such as NHibernate, or Entity Framework.

For a side project, I decided to set aside the familiar ASP.NET MVC framework in favor of learning a new language and a new corresponding framework. After a period of time spent deliberating over the virtues and drawbacks of each language, I chose Python for the language, and Django for the framework… and there was much rejoicing.

As I learned the language and read the Django docs, it became apparent to me that the MVC pattern can be implemented in various ways. MVC is not just whatever Microsoft says it is. The pattern (as with almost everything) is open to a little interpretation. So I needed to come to terms with the absence of some tools that I was used to having in ASP.NET MVC, as well as the unfamiliar terminology in the Django framework.

Introducing Django (it is not a CMS)

The first thing I would like to point out, is that Django is not a CMS. Django is to Python as ASP.NET MVC is to C#. I was surprised to find that out. My first impression of Django was that it was like Drupal, or Wordpress. I thought it was more like a CMS than a framework.

Having said that, Django’s administration scaffolding is amazing. Almost to the point that it could appear to be a pre-built CMS. Django is literally capable of generating an entire administration section that allows you to manage data in your database as defined by your MVC models. That is something that ASP.NET MVC is capable of doing to a certain degree, when an application uses Entity Framework, but they do it a little differently. ASP.NET MVC Scaffolding is completely dependant on Visual Studio’s ability to read your models and then generate code for your controllers. Though, in my experience I often have to go back and rewrite most of the generated code, and many-to-many relationships are sketchy, if they’re generated at all.

That isn’t the case for Django, which has it’s own built in ORM. Django is capable of complete scaffolding of many-to-many relationships, image and file uploaders, field validation, as well as basic input fields.

MVC actually stands for Model Template View

It’s semantics, I know. Read on.

Django Controllers Aren’t Called Controllers

To fulfill the MVC pattern, Django uses three primary divisions of code, the Model, the View, and the Template. Notice that there is no Controller.

Since I come from and ASP.NET MVC background, I was expecting code divisions that are labeled Model, View, and Controller (hence MVC). But no, this is not the case in Django. This fact caused some initial confusion for me as I was learning Django, but it doesn’t need to be confusing. If you’re familiar with ASP.NET MVC, then we just need to associate the Model, View, Controller concepts to the correct labels in Django.

Django’s Views are not ASP.NET MVC Views

When I think of Views in MVC, I think of the presentation layer which consists of markup, CSS, JavaScript, and some server-side scripting for basic display logic. That’s not what Views are in Django. Rather, Django’s Views do the equivalent job of the Controller in ASP.NET MVC. Templates are the Real Views

ASP.NET MVC uses the term ‘View’ to describe their presentation layer. HTML markup, css styles and JavaScript come together in a View file with help from Razor. Razor is very powerful and it is easy to pick up because it allows C# syntax directly in the view file to render a complete webpage. In my experience, this can also lead to an unbalanced View that has too much logic embedded in the View file instead of in the controller.

Django uses the term “Template' to describe their presentation layer. It also brings HTML markup, css styles, and JavaScript together. Though, it uses it’s own template rendering system. Whereas ASP.NET has the power of Razor that leverages C# syntax, Django’s template rendering syntax is unique, and it introduces a steeper learning curve than Razor.

If You’re Looking for Partial Views in Django…

…You’re probably not going to find them. There is nothing called “Partial Template” in Django, though you can accomplish similar functionality.

Let’s say you have a data driven navigation bar that you want to display on all your template pages. You don’t want to write all your views to explicitly query that data, create the nav object for the template, and then have the navigation markup located in each template. Rather, you would like to just have located in your template file a reference to a “Partial View' which would do all that for you and it is independent of View-specific processes. In ASP.NET, this can be accomplished with Partial Views. In Django, this can be accomplished with Template Tags. It seems to me to be more cumbersome than a Partial View concept, but that could just be because I am still relatively new to the Django framework. Models are Pretty Much What You Would Expect

Django has its own built in ORM. This allows you to define database tables, fields, validation, and relationships using Python classes. When you make changes to you Model’s classes, Django provides a simple command to sync the database:

$ python manage.py syncdb

These Model classes are editable through Django’s excellent scaffolding in the admin area, and they are queryable from Views for displaying in templates.

Is Django Better than ASP.NET MVC?

No, not really. Neither is ASP.NET better than Django. ASP.NET MVC and Django both have their weaknesses. They need to be selected based on the project specs. Also, familiarity is huge when considering what technology to use when starting a new project. I was looking for a low cost learning experience with my project, Python + Django was perfect for that. The project is now done, or perhaps more accurately described as ‘abandoned’, and I am glad that I explored it. I would probably use Django again, if the situation called for it. Though, I think first exploring other Python frameworks would be a good idea.