在钻研更多代码之前，让我们先花点时间考虑Django数据驱动Web应用的总体设计。Django的设计轨迹松耦合以及对应用程序中不同部分的严格分割。遵循这个理念的话，要想修改应用的某部分而不影响其他部分就比较容易了。在视图函数中，我们已经讨论过了通过模版系统把业务逻辑和表现逻辑分割开的重要性。在数据库层中，我们对数据访问逻辑也应用了同样的理念。把数据存取逻辑、业务逻辑和表现逻辑组合在一起的概念有时被称为软件架构的Model-View-Controller(MVC)模式。在这个模式中，Model代表数据存取层，View代表的是系统中选择显示什么和怎么显示的部分，Controller指的是系统中根据存取层，View代表的是系统中选择显示什么和怎么显示的部分，Controller指的是系统中根据用户输入及需要访问模型，以决定使用哪个视图的哪部分。

1.为什么缩写

像MVC这种明确定义模式的主要作用是改善开发人员之间的沟通。比起告诉同事，“让我们采用抽象的数据存取方式，然后单独划分一层来显示数据，并且在中间加上一个控制它的层”，一个通用的说法会让你受益，你只需说：“我们在这里使用MVC模式吧。”Django紧紧遵循这种MVC模式，可以称得上是一种MVC框架。下面是Django中M、V和C各自的含义：

M：数据存取部分，由Django数据库层处理

V：选择显示哪些数据以及怎样显示的部分，由视图和模版处理

C：根据用户输入委派视图的部分，由Django框架根据URLconf设置，对给定URL调用适当的Python函数。

2.MTV开发模式

由于C由框架自行处理，而Django里更关注的是模型（Model）、模版（Template）和视图（Views）,因此Django也被称为MTV框架。在MTV开发模型中：

M：代表模型（Model）,即数据存取层。该层处理与数据相关的所有事物，即如何存取、如何验证有效。

T：代表模版（Template）,即表现层。该层处理与表现相关的决定，即如何在页面或其他类型文档中进行显示。

V：代表视图（View）,即业务逻辑层。该层包含存取模型及调取恰当模版的相关逻辑。你可以把它看做是模型与模型之间的桥梁。

如果你熟悉其他的MVC Web开发框架，比如说Ruby on Rails,那么你可能会认为Django视图是控制器，而Django模版是试图。很不幸，这是对MVC不同诠释所引起的错误认识。在Django对MVC的诠释中，视图用来描述要展现给用户的数据；而不是数据如何展现以及展现哪些数据。相比之下，Ruby on Rails及一些同类框架提倡控制器负责决定向用户展现哪些数据，而视图仅决定如何展现数据，而不是展现哪些数据。

两种诠释种没有哪个更加正确一些，重要的是要理解底层概念。