Scribd
Upload
27 views1 page

And Clean, Pragmatic Design: The Presentation Is Tied To The Code

Uploaded by

arslanrck
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
27 views1 page

And Clean, Pragmatic Design: The Presentation Is Tied To The Code

Uploaded by

arslanrck
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Chapter 1: Introduction to Django

behavior to objects at runtime.

Beyond the productivity advantages inherent in Python, Django itself makes every effort to encourage rapid development. Every
part of the framework was designed with productivity in mind. We’ll see examples throughout this book.

…and clean, pragmatic design


Finally, Django strictly maintains a clean design throughout its own code and makes it easy to follow best Web-development
practices in the applications you create.

That means, if you think of Django as a car, it would be an elegant sports car, capable not only of high speeds and sharp turns,
but delivering excellent mileage and clean emissions.

The philosophy here is: Django makes it easy to do things the “right” way.

Specifically, Django encourages loose coupling: the programming philosophy that different pieces of the application should be
interchangeable and should communicate with each other via clear, concise APIs.

For example, the template system knows nothing about the database-access system, which knows nothing about the HTTP
request/response layer, which knows nothing about caching. Each one of these layers is distinct and loosely coupled to the rest.
In practice, this means you can mix and match the layers if need be.

Django follows the “model-view-controller” (MVC) architecture. Simply put, this is a way of developing software so that the code
for defining and accessing data (the model) is separate from the business logic (the controller), which in turn is separate from the
user interface (the view).

MVC is best explained by an example of what not to do. For instance, look at the following PHP code, which retrieves a list of
people from a MySQL database and outputs the list in a simple HTML page. (Yes, we realize it’s possible for disciplined
programmers to write clean PHP code; we’re simply using PHP to illustrate a point.):

<html>
<head><title>Friends of mine</title></head>
<body>
<h1>Friends of mine</h1>
<ul>
<?php
$connection = @mysql_connect("localhost", "my_username", "my_pass");
mysql_select_db("my_database");
$people = mysql_query("SELECT name, age FROM friends");
while ( $person = mysql_fetch_array($people, MYSQL_ASSOC) ) {
?>
<li>
<?php echo $person['name'] ?> is <?php echo $person['age'] ?> years old.
</li>
<?php } ?>
</ul>

</body>
</html>

While this code is conceptually simple for beginners — because everything is in a single file — it’s bad practice for several reasons:

1. The presentation is tied to the code. If a designer wanted to edit the HTML of this page, he or she would have to edit this
code, because the HTML and PHP core are intertwined.

By contrast, the Django/MVC approach encourages separation of code and presentation, so that presentation is governed by
templates and business logic lives in Python modules. Programmers deal with code, and designers deal with HTML.

2. The database code is tied to the business logic. This is a problem of redundancy: If you rename your database tables or
columns, you’ll have to rewrite your SQL.

By contrast, the Django/MVC approach encourages a single, abstracted data-access layer that’s responsible for all data
access. In Django’s case, the data-access layer knows your database table and column names and lets you execute SQL
queries via Python instead of writing SQL manually. This means, if database table names change, you can change it in a
single place — your data-model definition — instead of in each SQL statement littered throughout your code.

3. The URL is coupled to the code. If this PHP file lives at /foo/index.php, it’ll be executed for all requests to that address.
But what if you want this same code to execute for requests to /bar/ and /baz/? You’d have to set up some sort of includes
or rewrite rules, and those get unmanageable quickly.

file:///C|/Documents and Settings/Suren/Desktop/Chapter 1 Introduction to Django.htm (2 of 4)9/28/2007 4:13:54 PM

You might also like