CHAPTER 1 UNDERSTANDING DJANGO
3
While this pattern has proven very effective in many domains, Django’s authors weren’t
looking to conform to any form of pattern at the outset. They were simply interested in finding
the most effective way to develop software for the Web. After all, Django was built for the daily
needs of a working newspaper, where things have to happen very quickly if they’re to happen
at all. Ultimately, the separation of tasks into discrete groups serves a few different purposes.
doesn’t need to make assumptions about completely unrelated parts of the application.
-
ferent view and controller layers may connect to a single model layer. This enables
a
variety of applications to share the same business logic and data, presenting it and
interacting with it in different ways, for different audiences.
work being performed. This specialization helps to curb frustration and fatigue, while
fostering creativity and excellence within each developer’s domain of specialty.
There are certainly other smaller benefits, but these are generally the main goals achieved
with the use of MVC. It’s interesting to note, however, that the only part of those benefits that
applies to any specific division in the MVC pattern is the ability to plug multiple applications
into a single model layer. The rest is just an arbitrary division based on common development
plans.
Django’s developers sought these same benefits, but with an emphasis on rapid development,
without worrying about creating a development pattern. After getting a set of tools that made sense
for their workflow, they ended up with what some have called a Model-Template- View (MTV)
pattern. However, there are really four primary code divisions in a Django application, which are
outlined next.
Model
Given the benefit of keeping models apart from the rest of the application, Django follows that
part of MVC to the letter. Django models provide easy access to an underlying data storage
mechanism, and can also encapsulate any core business logic, which must always remain in
effect, regardless of which application is using it.
Models exist independent of the rest of the system, and are designed to be used by any
application that has access to them. In fact, the database manipulation methods that are avail-
able on model instances can be utilized even from the interactive interpreter, without loading
a Web server or any application- specific logic.
Chapter 3 covers Django models in more detail, including how they’re defined and uti-
lized, how to include your own business logic and much more.
View
While they share a name with the original MVC definition, Django views have little else in
common with the traditional paradigm. Instead, they combine some of the traditional view’s
responsibility with the entirety of the controller’s tasks. A view accepts user input, including
simple requests for information; behaves according to the application’s interaction logic; and
returns a display that is suitable for users to access the data represented by models.