In this article we are going to discuss about Architectural pattern for DJANGO.
Software Architectural Patterns
Before we dive into the code, let's review two of the most popular server-side software architectural design patterns: Model-View-Controller and Presentation-Abstraction-Control.
The Model-View-Controller (MVC) design pattern is a software architecture pattern which separates the presentation of data from the logic of handling user interactions. A model specifies what kind of data gets stored. A view requests data from a model and generates outputs from it. A controller provides logic to change the view's presentation or update the model's data.
Like MVC, Presentation-Abstraction-Control (PAC) is another popular software architectural pattern. PACseparates the system into layers of components. Within each layer, the presentation component generates output from the input data; the abstraction component retrieves and processes data; and the controlcomponent is the middleman between presentation and abstraction which manages the flow of information and the communication between these components. Unlike MVC, where a view talks directly to a model, PAC's presentation and abstraction never talk directly to each other and the communication between them is mediated by control. Unlike Django which follows the MVC pattern, the popular content management system Drupal follows the PAC pattern.
MVC in DJANGO
MVC has been around as a concept for a long time, but has seen exponential growth since the advent of the Internet because it is the best way to design client-server applications. All of the best web frameworks are built around the MVC concept. At the risk of starting a flame war, I contest that if you are not using MVC to design web apps, you are doing it wrong. As a concept,
the MVC design pattern is really simple to understand:
- The model(M) is a model or representation of your data. It’s not the actual data, but an interface to the data. The model allows you to pull data from your database without knowing the intricacies of the underlying database. The model usually also provides an abstractionlayer with your database, so that you can use the same model with multiple databases.
- The view(V) is what you see. It’s the presentation layer for your model. On your computer,
the view is what you see in the browser for a Web app, or the UI for a desktop app. The view also provides an interface to collect user input.
- The controller(C) controls the flow of information between the model and the view. It uses programmed logic to decide what information is pulled from the database via the model and what information is passed to the view. It also gets information from the user via the view and implements business logic: either by changing the view, or modifying data through the model, or both.
Django follows the MVC pattern closely, however it does use its own logic in the implementation. Because the “C” is handled by the framework itself and most of the excitement in Django happens in models, templates and views, Django is often referred to as an MTV framework. In the MTV development pattern:
- M stands for “Model,” the data access layer. This layer contains anything and everything about the data: how to access it, how to validate it, which behaviors it has, and the relationships between the data. We will be looking closely at Django’s models in Chapter 4.
- T stands for “Template,” the presentation layer. This layer contains presentation-related decisions: how something should be displayed on a Web page or other type of document. We will explore Django’s templates in Chapter 3.
- V stands for “View,” the business logic layer. This layer contains the logic that accesses the model and defers to the appropriate template(s). You can think of it as the bridge between models and templates.
Django and its Features
Django was first released in the year 2005 and is aimed at large applications. It includes an ORM, which allows you to switch between various relational databases quickly. It even provides an MVC and Django REST framework. Let us have a look at its features,
Django REST framework supports REST-ful API and an inbuilt user model API for authorization and authentication. Thus it supports human-friendly HTML output generation for a resource when the HTML format is requested. These pages allow you to easily browse for resources and developers can execute GET and POST easily in their browsers. This browsable API is built with Bootstrap, making customization simple.
Since Django includes an ORM, it allows various relational databases like PostgreSQL, Oracle, MySQL, SQLite etc to interact with application data. Django allows models and easy creation of tables and fields automatically. Also, changes like creating tables and indexes are rolled out with a single command
Django comes with an automatic and very customizable admin panel. This admin panel makes the production and development of a CMS (Content Management System) very easy.
Both have a built-in ORM (or Object Relational Mapper) that allows database queries to be written in Python or Ruby code directly instead of using SQL statements. The ORM then handles communicating with the database. This level of abstraction helps in writing code, but also makes it easier to switch between different relational databases. For example, if you’re using SQLite in development, you can switch to PostgreSQL when you deploy with minimal code modifications.
Models and Migrations
Both also have database migrations, which are extremely helpful in propagating changes you make to your models into your database schema. These migrations also act like a version control system for your database. One old complaint about Django is that it didn’t originally have migrations, but those have been included for a few years now since Django 1.7. I personally prefer Django’s way of organizing models and database migrations. In Django, when you want to change a table, you (1) change the model file (
models.py) directly, and (2) start the migration commands
migrate. Then, the corresponding table in the database is changed. And you can then find your model definitions and fields in one place: the
design particle : http://www.djangocrew.com/blog/django-framework-design-principles/
blog comments powered by Disqus