Django 中的MTV开发模式

在我们专研更多的代码之前，让我们先花点时间考虑一些Django Web程序的整体设计
前面的章节我们提到，Django设计来鼓励松耦合和分离程序模块
如果你遵循这个哲学，改变一部分代码而不影响其它模块是很容易做到的
例如在视图方法里，我们讨论了使用模板来分离业务逻辑和呈现逻辑的重要性
在数据库层的数据访问逻辑我们将遵循同样的哲学
数据访问，业务逻辑和呈现逻辑组成常说的“Model View Controller”(MVC)软件架构模式
“Model”指数据访问层，“View”指系统中选择什么来呈现以及怎样呈现的部分
“Controller”则指系统中通过用户输入决定使用哪个视图及访问必要的模型的部分
采用MVC,MTV等缩写只是便于开发人员沟通
Django遵循了MVC模式，它可以被称位MVC框架，下面是M,V,C在Django中的位置：
1，M，数据据访问部分，通过Django的数据库层处理
2，V，选择数据并决定怎样呈现的部分，通过视图和模板来处理
3，C，控制部分通过Django框架本身的URL配置和对Python方法的调用来处理
因为“C”是Django框架本身处理而导致Django大部分精彩的东西在于模型，模板和视图
所以Django被称位MTV框架：
1，M，代表模型，是数据访问层，它包含了关于数据的一切东西，怎样得到数据，怎样验证数据，
它具有什么行为以及数据之间的关系
2，T，代表模板，是展现层，它包含了呈现相关的决策，如内容怎样在Web页面中显示以及其它类型的文档
3，V，代表视图，是业务逻辑层，它包含了访问模型的逻辑和选择合适的模板
你可以认为视图是模型和模板的桥梁
如果你对MVC框架熟悉，如Ruby on Rails，你可以把Django的视图想象成“controllers”，
把Django的模板想象成“views”，这是对MVC的不同解释造成的不幸的混乱
在Django关于MVC的解释中，“view”描述呈现给用户的数据
没有必要弄清数据怎样显示，而是描述哪个数据应该被呈现
对比而言，Ruby on Rails以及类似的框架建议controller的工作包括决定哪个数据显示给用户，
视图严格的决定数据怎样显示，而不是决定哪个数据来显示
每一个解释都不比另一个正确，最重要的事情是理解底层的概念