設計思想¶
This document explains some of the fundamental philosophies Django’s developers have used in creating the framework. Its goal is to explain the past and guide the future.
概要¶
疎結合¶
A fundamental goal of Django’s stack is loose coupling and tight cohesion. The various layers of the framework shouldn’t “know” about each other unless absolutely necessary.
For example, the template system knows nothing about Web requests, the database layer knows nothing about data display and the view system doesn’t care which template system a programmer uses.
Although Django comes with a full stack for convenience, the pieces of the stack are independent of another wherever possible.
短いコード¶
Django apps should use as little code as possible; they should lack boilerplate. Django should take full advantage of Python’s dynamic capabilities, such as introspection.
素早い開発¶
The point of a Web framework in the 21st century is to make the tedious aspects of Web development fast. Django should allow for incredibly quick Web development.
同じことを繰り返さない (DRY)¶
Every distinct concept and/or piece of data should live in one, and only one, place. Redundancy is bad. Normalization is good.
The framework, within reason, should deduce as much as possible from as little as possible.
暗黙よりもはっきり示した方がいい (Explicit is better than implicit)¶
This is a core Python principle listed in PEP 20, and it means Django shouldn’t do too much “magic.” Magic shouldn’t happen unless there’s a really good reason for it. Magic is worth using only if it creates a huge convenience unattainable in other ways, and it isn’t implemented in a way that confuses developers who are trying to learn how to use the feature.
一貫性¶
フレームワークはあらゆるレベルで一貫性を持たなければなりません。一貫性は、低レベル (採用する Python のコーディングスタイル) から高レベル (Django の使い方) までのあらゆる点で保たれなければなりません。
モデル¶
暗黙よりもはっきり示した方がいい (Explicit is better than implicit)¶
Fields shouldn’t assume certain behaviors based solely on the name of the field. This requires too much knowledge of the system and is prone to errors. Instead, behaviors should be based on keyword arguments and, in some cases, on the type of the field.
Include all relevant domain logic¶
Models should encapsulate every aspect of an “object,” following Martin Fowler’s Active Record design pattern.
This is why both the data represented by a model and information about it (its human-readable name, options like default ordering, etc.) are defined in the model class; all the information needed to understand a given model should be stored in the model.
データベース API¶
The core goals of the database API are:
SQL の効率性¶
It should execute SQL statements as few times as possible, and it should optimize statements internally.
This is why developers need to call save() explicitly, rather than the
framework saving things behind the scenes silently.
This is also why the select_related() QuerySet method exists. It’s an
optional performance booster for the common case of selecting “every related
object.”
Terse, powerful syntax¶
The database API should allow rich, expressive statements in as little syntax as possible. It should not rely on importing other modules or helper objects.
Joins should be performed automatically, behind the scenes, when necessary.
Every object should be able to access every related object, systemwide. This access should work both ways.
Option to drop into raw SQL easily, when needed¶
The database API should realize it’s a shortcut but not necessarily an
end-all-be-all. The framework should make it easy to write custom SQL – entire
statements, or just custom WHERE clauses as custom parameters to API calls.
URL デザイン¶
疎結合¶
URLs in a Django app should not be coupled to the underlying Python code. Tying URLs to Python function names is a Bad And Ugly Thing.
Along these lines, the Django URL system should allow URLs for the same app to
be different in different contexts. For example, one site may put stories at
/stories/, while another may use /news/.
Infinite flexibility¶
URLs should be as flexible as possible. Any conceivable URL design should be allowed.
ベストプラクティスの推奨¶
The framework should make it just as easy (or even easier) for a developer to design pretty URLs than ugly ones.
File extensions in Web-page URLs should be avoided.
Vignette-style commas in URLs deserve severe punishment.
Definitive URLs¶
Technically, foo.com/bar and foo.com/bar/ are two different URLs, and
search-engine robots (and some Web traffic-analyzing tools) would treat them as
separate pages. Django should make an effort to “normalize” URLs so that
search-engine robots don’t get confused.
This is the reasoning behind the APPEND_SLASH setting.
テンプレートシステム¶
ロジックのプレゼンテーションからの分離¶
We see a template system as a tool that controls presentation and presentation-related logic – and that’s it. The template system shouldn’t support functionality that goes beyond this basic goal.
冗長性の排除¶
The majority of dynamic websites use some sort of common sitewide design – a common header, footer, navigation bar, etc. The Django template system should make it easy to store those elements in a single place, eliminating duplicate code.
これが テンプレートの継承 の背後にある思想です。
HTML と疎結合であれ¶
テンプレートシステムは、ただ単に HTML だけを出力するように設計されてはいません。他のテキストベースのフォーマットや、単純なプレインテキストも同じように上手く生成できるように作られています。
テンプレート言語として、XML を使うべきではない¶
テンプレートをパースするのに XML エンジンを使ってしまうと、テンプレートの編集に全く新しいヒューマンエラーの世界を作り出してしまい、結果として、テンプレート処理に受け入れられないようなレベルの困難を生み出してしまうでしょう。
Assume designer competence¶
The template system shouldn’t be designed so that templates necessarily are displayed nicely in WYSIWYG editors such as Dreamweaver. That is too severe of a limitation and wouldn’t allow the syntax to be as nice as it is. Django expects template authors are comfortable editing HTML directly.
ホワイトスペースを明示的に扱う¶
テンプレートシステムは、ホワイトスペースに対して変わった処理を行うべきではありません。もしテンプレートにホワイトスペースが書かれていれば、他の文字と同じように扱って、それをそのまま表示するべきです。テンプレートタグの外に書かれたすべてのホワイトスペースは、そのまま表示するべきです。
新しいプログラミング言語を開発しない¶
私たちの目的は、新しいプログラミング言語を開発することではありません。本当の目的は、プログラミング言語が持つような機能を必要十分なだけ使えるようにすることです。たとえば、条件分岐やループといったもので、これらはプレゼンテーションに関連する決定を下すときに大切になります。 Django テンプレート言語 (Django Template Language; DTL) は、複雑なロジックを使わずにこの目的を達成するために作られました。
Django のテンプレートシステムは、テンプレートの書き手は プログラマー ではなく、主に デザイナー であることを念頭に置いています。そのため、Python の知識がまったくなくても書けるようになっています。
安全性とセキュリティ¶
テンプレートシステムは、コマンドの実行やデータベースレコードの削除を行うような、悪意のあるコードの挿入ができないようになっていなければなりません。
これが、テンプレートシステムが任意の Python コードの実行を許さないようにできているもう一つの理由です。
拡張性¶
The template system should recognize that advanced template authors may want to extend its technology.
これが、カスタムテンプレートタグとフィルタの背後にある思想です。
ビュー¶
シンプルであること¶
ビューは、Python の関数を書くのと同じくらい簡単に書けるべきです。開発者は、ふつうに関数を書くときと同じように、クラスからインスタンスを作ったりせずにビューが書けるべきです。
request オブジェクトを使うこと¶
Views should have access to a request object – an object that stores metadata about the current request. The object should be passed directly to a view function, rather than the view function having to access the request data from a global variable. This makes it light, clean and easy to test views by passing in “fake” request objects.
疎結合¶
ビューは、開発者がどのテンプレートシステムを使用しているか意識せずに使えるべきです。もっと言えば、テンプレートシステム自体を使っているかどうかも気にせずに使えるようにするべきです。
GET と POST を区別¶
GET と POST は区別します。開発者は明示的に一方を他方と区別して明示的に使用するべきです。フレームワークは、GET と POST データを分かりやすく区別できるようにしなければなりません。
キャッシュフレームワーク¶
Django の キャッシュフレームワーク の主な目的は次の点にあります。
短いコード¶
キャッシュは可能な限り高速でなければならない。したがって、キャッシュバックエンドを包んでいるフレームワークのコード (特に get() 操作) はすべて、極限まで短くするべきである。
一貫性¶
キャッシュ API は、バックエントが違っていても一貫したインターフェイスを提供するべきである。
拡張性¶
キャッシュ API は、開発者のニーズにもとづいて、アプリケーションレベルで拡張可能であるべきである (例としては Cache key transformation がある)。
