本文档解释了 Django 开发人员在开发 Django 时使用的一些基本哲学， 它的目标是解释过去并指导未来
\nDjango 栈的基本目标是降低耦合度同时加强聚合度。框架里的不同层（Layers）不应该知道对方的代码，除非它们确实需要。
\n例如，模板系统不需要知道用户的 Web 请求，数据库层不需要了解如果显示数据，而视图并不关心程序员所使用的模板系统。
\n尽管为了方便 Django 带有一个完整的堆栈，但堆栈的各个部分尽可能独立于另一个堆栈。
\nDjango应用的代码应该尽可能地精简，Django应该充分利用Python的动态能力，比如自省机制（introspection）
\n在 21 世纪，Web 框架的核心一点是让 Web 开发中枯燥的事情处理得更加快速，Django 可以做到快速的 Web 开发。
\n每个独特的概念或数据片应该存在且只存在于一个地方。避免冗余，做好标准化。
\n合理的框架应该从尽可能少的信息中推断出尽可能多的需求。
\n\n这是在 PEP 20 列出的核心 Python 原则，这意味着 Django 不应该使用太多的“魔术”。除非有一个很好的理由，否则不应该出现魔术。只有当魔术创造了巨大的便利，并且使用其他方式难以实现时，它才值得使用，而且它的实现方式并不会让试图学习如何使用该功能的开发人员感到困惑。
\n框架应在所有层级上保持一致。一致性适用于从低级（Python 的编码风格）到高级（使用 Django 的“经验”）的所有内容。
\n字段不应该仅仅根据字段的名称来假定某些行为。这需要对系统有太多了解，并且容易出现错误。相反，其行为应该基于关键字参数，并且在某些情况下，应该基于字段的类型。
\n模型应该封装一个“对象”的各个方面，遵循 Martin Fowler 的“Active Record”设计模式。
\n这就是为什么在模型类中要同时定义一个模型表现的数据以及关于它的信息（其人类可读的名称，默认排序等选项）；所有用于理解给定模型所需的信息都应该存储在模型中。
\n数据库API的主要用处：
\n它应该尽可能少地执行SQL语句，并且应该在内部优化语句。
\n这就是为什么开发者需要显式地调用“save()”，而不是由框架静默地在幕后保存东西。
\n这也是为什么“select_related()”“QuerySet”方法存在的原因。在查询“每个关联的对象”的常见情况下，它是一个可选的性能提升器。
\n数据库 API 应该允许用尽可能少的语法，来表达丰富、达意的语句。它不应该依赖于导入其他模块或辅助对象。
\n当必要时, 在幕后插入应该是自动进行的.
\n每一个对象都应该能够访问所有相关的目的, 系统范围. 这种访问应该是双向的.
\n应该认识到数据库 API 只是一个便捷的方法，但并不必须是最终的全部手段。框架应该可以很容易地编写自定义的 SQL——完整的语句，或者仅仅是自定义“WHERE”子句作为 API 调用时的自定义参数。
\nDjango 应用中的 URL 不应该与底层 Python 代码耦合。将 URL 与 Python 函数名联系起来是一件很糟糕且丑陋的做法。
\n按照这些方法，Django URL 系统应该允许同一应用的 URL 在不同的上下文中有所不同。例如，一个网站可以在“/stories/”中放置故事，而另一个网站则可以使用“/news/”。
\nURL 应该尽可能灵活。任何可想到的 URL 设计都应该被允许。
\n框架可以做到让开发者简单（或更加简单）地设计出漂亮的，而不是难看的 URL。
\n在 URL 中应避免出现文件后缀名。
\n在 URL 中使用 Vignette 式的逗号应该受到严厉的惩罚。
\n技术上，foo.com/bar 和 foo.com/bar/ 是两条不同的 URL，搜索引擎爬虫（以及某些 Web 流量分析工具）会将其视为独立的页面。Django 会将其转为 "标准" 的 URL，让搜索引擎爬虫正确识别。
详细请参考：setting:APPEND_SLASH setting.
\nWe see a template system as a tool that controls presentation and\npresentation-related logic -- and that's it. The template system shouldn't\nsupport functionality that goes beyond this basic goal.
\nThe majority of dynamic websites use some sort of common sitewide design --\na common header, footer, navigation bar, etc. The Django template system should\nmake it easy to store those elements in a single place, eliminating duplicate\ncode.
\nThis is the philosophy behind template inheritance.
\nThe template system shouldn't be designed so that it only outputs HTML. It\nshould be equally good at generating other text-based formats, or just plain\ntext.
\nUsing an XML engine to parse templates introduces a whole new world of human\nerror in editing templates -- and incurs an unacceptable level of overhead in\ntemplate processing.
\nThe template system shouldn't be designed so that templates necessarily are\ndisplayed nicely in WYSIWYG editors such as Dreamweaver. That is too severe of\na limitation and wouldn't allow the syntax to be as nice as it is. Django\nexpects template authors are comfortable editing HTML directly.
\nThe template system shouldn't do magic things with whitespace. If a template\nincludes whitespace, the system should treat the whitespace as it treats text\n-- just display it. Any whitespace that's not in a template tag should be\ndisplayed.
\nThe goal is not to invent a programming language. The goal is to offer just\nenough programming-esque functionality, such as branching and looping, that is\nessential for making presentation-related decisions. The Django Template\nLanguage (DTL) aims to avoid advanced logic.
\nThe Django template system recognizes that templates are most often written by\ndesigners, not programmers, and therefore should not assume Python\nknowledge.
\n开箱即用的模板系统禁止包含恶意代码，例如删除数据库记录的代码。
\n这就是模板系统不允许有任意Python代码的另一个原因。
\n模板系统应该认识到, 高阶的模板作者可能想扩展它.
\n这是自定义的模板标签和过滤器背后的理念.
\n编写视图应该和编写Python函数一样简单。开发人员不应该在函数执行时实例化一个类。
\nViews should have access to a request object -- an object that stores metadata\nabout the current request. The object should be passed directly to a view\nfunction, rather than the view function having to access the request data from\na global variable. This makes it light, clean and easy to test views by passing\nin "fake" request objects.
\n视图不应该关心开发人员使用哪种模板——甚至根本不用模板系统。
\nGET and POST are distinct; developers should explicitly use one or the other.\nThe framework should make it easy to distinguish between GET and POST data.
\nThe core goals of Django's cache framework are:
\nA cache should be as fast as possible. Hence, all framework code surrounding\nthe cache backend should be kept to the absolute minimum, especially for\nget() operations.
The cache API should provide a consistent interface across the different\ncache backends.
\nThe cache API should be extensible at the application level based on the\ndeveloper's needs (for example, see Cache key transformation).
\n