Wednesday, March 14th, 2012

How do you code in MVC/MTV?

Model-view-controller or what Django calls Model-Template-View is a global programming phenomenon. Even though it was around for many decades, it was not as widely used as it is today.

I am a firm believer in this type of programming. I once programmed everything using a flat style, where everything is fused together. Once I moved over to MVC/MTV, I found that debugging and adding new abilities to an application much more seamless. Porting applications from one fontend to another is also much easier when using an MVC/MTV.

There are many ways to code an MVC/MTV application. You can begin from coding from almost any point. Do you want to work on what the user sees first? Go for it. Rather model your database first? Done. It's very easy to start developing from any point you feel fit. Sometimes this can also depend on the application being developed. An application which is very data-centric may have the model data developed first, then build the front-end components to fit the data into afterwards.

Personally, I find it easier to prototype the models of my application first, and doing do in Django is a dream. This is mainly due to Django's auto-admin interface. I can see and work with the data as soon as a I model it to see it interact with other models in the set. This is especially helpful when working for JOINs, as it helps visualize the development process and brainstorm without needing to write any front-end code.

This is why I see Django as a great model prototyping toolkit. Even if you don't want to use Django for your final product( as you might be building a desktop app ), it helps to visualize and work with test data while building your models. Django works really well on it's own, it doesn't require much configuration and can use an SQLite database. It also comes with a built in development server, so there is no external requirements but Python and Django. The Django admin interface is very customizable, with inline datasets and such, it definitely makes prototyping databases very easy. I guess you can say, Django is very multipurpose and doesn't need to be used as a web framework at all.

The only problem with Django is that it does not use SQLAlchemy natively, so the admin interface will not work with it. This poses an interesting problem about model portability. If you create your web application in Django, and then want to go and use another framework with the same dataset. You have a few choices:

  1. Use the Django ORM in your other framework.
  2. Use SQLAlchemy's inspect ability and use SQLAlchemy.
  3. Port the datasets over to a new model format.
Okay, so the final one there is the least likeliest. The first one will bloat your new code with unnecessary Django configuration data required for the ORM to work. The second option is going to be the most preferred.

Using Django's inspect ability can allow one to port other applications to Django, however the resulting code will need to be modified in order to take advantage of Django specific ORM features.

About Me

My Photo
Names Kevin, hugely into UNIX technologies, not just Linux. I've dabbled with the demons, played with the Sun, and now with the Penguins.




Kevin Veroneau Consulting Services
Do you require the services of a Django contractor? Do you need both a website and hosting services? Perhaps I can help.

This Month

If you like what you read, please consider donating to help with hosting costs, and to fund future books to review.

Python Powered | © 2012-2013 Kevin Veroneau