A .Net Developer’s Initial Thoughts on the Django Framework

Python has been my ‘I need to learn this sometime soon’ language for the past two years. I’m not sure why. A few weeks ago, I started playing around with it to learn the basic syntax using code katas. That was fun. But while code katas help one figure out ways to solve common problems, many of them are really language agnostic, and one can’t really build something useful using knowledge gained only from code katas. This week, I had some spare time and decided to play around more with the Django framework for python.

Now the code katas did help, because now I understood the basics of the languages like class and method declarations, how variables work, etc. This helped the easing into the tutorial I used to help me learn the framework.

Here are my initial thoughts on the framework.

• It’s an MVC framework very similar to ASP.Net MVC besides a few semantics. The words used for concepts are different, but the basic structure is the same: – Templates in the Django framework are synonymous with Views in ASP.Net MVC. In Django, templating is done using these html files called Templates and in ASP.Net MVC, templating is done using cshtml files.
• Views in the Django framework are synonymous with controller methods in ASP.Net MVC. This was a bit confusing at first. Views mean different things in the different language frameworks, but they actually do the same thing.
• Routes are done differently. In the Django framework, routes are specified using regular expressions in the url.py file. In ASP.Net MVC, routes are either automagically determined using the controller name and controller method, or can be specified using the Route attribute. I’m not very familiar with regular expressions at the moment, so I favoured the ASP.NET MVC approach here. The Flask framework for Python has a similar approach as the Route attributes in ASP.NET MVC.
• With Django, the ORM is part of the framework. I’m not sure how I feel about this. I’m from a world where the data-access layer is abstracted to ease testing as well as to prevent tight coupling between the data access framework and the application logic. There are other ORM’s that one can use e.g. SQL Alchemy, but I haven’t found any online discussions where the data access layer is abstracted.
• The unit testing framework which forms a part of Django is interesting. It creates its own test database. I guess this is how they make the close coupling of the ORM and the application logic ‘testable’. I still don’t like it.

Overall, it’s a really great framework. I really liked the idea of changing something in the source code, and have it reflected on the front end immediately without having to build and recompile the source code. It seems to make for faster development. Over the next few weeks, I’m going to attempt to make a simple application I’ve been thinking about, using Python and the Django framework. Watch this space.