Философии дизайна¶

Свободное соединение¶

Фундаментальной целью стека Django является loose coupling and tight cohesion. Различные уровни фреймворка не должны «знать» друг о друге без крайней необходимости.

Например, система шаблонов ничего не знает о Web-запросах, уровень базы данных ничего не знает об отображении данных, а системе представления все равно, какую систему шаблонов использует программист.

Хотя Django поставляется с полным стеком для удобства, части стека по возможности независимы друг от друга.

Меньше кода¶

Приложения Django должны использовать как можно меньше кода; в них не должно быть шаблонов. Django должен использовать все преимущества динамических возможностей Python, таких как интроспекция.

Быстрое развитие¶

Смысл веб-фреймворка в 21 веке заключается в том, чтобы сделать утомительные аспекты веб-разработки быстрыми. Django должен обеспечивать невероятно быструю веб-разработку.

Не повторяйтесь (DRY)¶

Каждая отдельная концепция и/или часть данных должна жить в одном, и только в одном месте. Избыточность - это плохо. Нормализация - это хорошо.

Система, в пределах разумного, должна выводить как можно больше из как можно меньшего.

Явное лучше неявного¶

Это основной принцип Python, перечисленный в PEP 20, и он означает, что Django не должен делать слишком много «волшебства». Магия не должна происходить, если для этого нет действительно веской причины. Магию стоит использовать, только если она создает огромное удобство, недостижимое другими способами, и она не реализована таким образом, чтобы сбить с толку разработчиков, которые пытаются научиться использовать эту функцию.

Последовательность¶

Фреймворк должен быть последовательным на всех уровнях. Согласованность относится ко всему, от низкого уровня (используемый стиль кодирования Python) до высокого уровня («опыт» использования Django).

Явное лучше неявного¶

Поля не должны предполагать определенное поведение, основываясь только на названии поля. Это требует слишком много знаний о системе и чревато ошибками. Вместо этого поведение должно основываться на аргументах ключевых слов и, в некоторых случаях, на типе поля.

Включите всю соответствующую логику домена¶

Модели должны инкапсулировать все аспекты «объекта», следуя шаблону проектирования Мартина Фаулера Active Record.

Вот почему и данные, представленные моделью, и информация о ней (ее человекочитаемое имя, опции, такие как упорядочивание по умолчанию, и т.д.) определяются в классе модели; вся информация, необходимая для понимания данной модели, должна храниться в модели.

Эффективность SQL¶

Он должен выполнять SQL-операторы как можно меньше раз и оптимизировать их внутреннюю оптимизацию.

Именно поэтому разработчикам необходимо явно вызывать save(), вместо того, чтобы фреймворк сохранял все за кулисами молча.

Именно поэтому существует метод select_related() QuerySet. Это дополнительное средство повышения производительности для распространенного случая выбора «каждого связанного объекта».

Лаконичный, мощный синтаксис¶

API базы данных должен обеспечивать богатые, выразительные высказывания с минимально возможным синтаксисом. Он не должен полагаться на импорт других модулей или вспомогательных объектов.

Присоединения должны выполняться автоматически, за сценой, когда это необходимо.

Каждый объект должен иметь доступ к каждому связанному с ним объекту в масштабах всей системы. Этот доступ должен работать в обоих направлениях.

Возможность легко перейти на необработанный SQL, когда это необходимо¶

API базы данных должен понимать, что это короткий путь, но не обязательно конечная цель. Фреймворк должен упрощать написание пользовательского SQL - целых операторов или просто пользовательских предложений WHERE в качестве пользовательских параметров для вызовов API.

Свободное соединение¶

URL в приложении Django не должны быть связаны с базовым кодом Python. Привязывать URL к именам функций Python - это плохо и некрасиво.

В соответствии с этим, система URL Django должна позволять URL для одного и того же приложения быть разными в разных контекстах. Например, один сайт может размещать истории по адресу /stories/, а другой может использовать /news/.

Бесконечная гибкость¶

URL-адреса должны быть максимально гибкими. Должна быть разрешена любая возможная конструкция URL.

Поощрение передового опыта¶

С помощью фреймворка разработчику должно быть так же легко (или даже легче) создавать красивые URL-адреса, чем некрасивые.

Следует избегать использования расширений файлов в URL-адресах веб-страниц.

Запятые в URL в стиле виньетки заслуживают сурового наказания.

Определяющие URL-адреса¶

Технически, foo.com/bar и foo.com/bar/ - это два разных URL, и роботы поисковых систем (и некоторые инструменты анализа веб-трафика) будут воспринимать их как отдельные страницы. Django должен приложить усилия для «нормализации» URL, чтобы роботы поисковых систем не путались.

Именно это и является причиной установки APPEND_SLASH.

Отделите логику от презентации¶

Мы рассматриваем систему шаблонов как инструмент, который управляет презентацией и логикой, связанной с презентацией - и это все. Система шаблонов не должна поддерживать функциональность, выходящую за рамки этой основной цели.

Не допускайте избыточности¶

Большинство динамических веб-сайтов используют некий общий дизайн сайта - общий верхний колонтитул, нижний колонтитул, панель навигации и т.д. Система шаблонов Django должна упростить хранение этих элементов в одном месте, устраняя дублирование кода.

Это философия, лежащая в основе template inheritance.

Быть отделенным от HTML¶

Система шаблонов не должна быть спроектирована так, чтобы она выводила только HTML. Она должна одинаково хорошо генерировать другие текстовые форматы или просто текст.

XML не следует использовать для языков шаблонов¶

Использование механизма XML для разбора шаблонов создает целый мир человеческих ошибок при редактировании шаблонов - и влечет за собой неприемлемый уровень накладных расходов при обработке шаблонов.

Предполагать компетентность дизайнера¶

Система шаблонов не должна быть разработана так, чтобы шаблоны обязательно красиво отображались в редакторах WYSIWYG, таких как Dreamweaver. Это слишком жесткое ограничение, которое не позволит синтаксису быть таким красивым, как он есть. Django ожидает, что авторам шаблонов будет удобно редактировать HTML напрямую.

Обращайтесь с пробелами явно¶

Система шаблонов не должна делать магические вещи с пробелами. Если шаблон включает пробельные символы, система должна относиться к пробельным символам так же, как к тексту - просто отображать их. Любой пробел, не входящий в тег шаблона, должен отображаться.

Не изобретайте язык программирования¶

Цель не в том, чтобы изобрести язык программирования. Цель состоит в том, чтобы предложить достаточно функциональности, напоминающей программирование, такой как ветвление и цикл, которая необходима для принятия решений, связанных с презентацией. Django Template Language (DTL) стремится избежать продвинутой логики.

Система шаблонов Django признает, что шаблоны чаще всего пишутся дизайнерами, а не программистами, и поэтому не должны предполагать знание Python.

Охрана и безопасность¶

Система шаблонов из коробки должна запрещать включение вредоносного кода - например, команд, удаляющих записи базы данных.

Это еще одна причина, по которой система шаблонов не позволяет использовать произвольный код Python.

Расширяемость¶

Система шаблонов должна понимать, что продвинутые авторы шаблонов могут захотеть расширить ее технологию.

В этом заключается философия пользовательских тегов шаблонов и фильтров.

Простота¶

Написание представления должно быть таким же простым, как написание функции в Python. Разработчикам не нужно инстанцировать класс, если для этого достаточно функции.

Используйте объекты запроса¶

Представления должны иметь доступ к объекту запроса - объекту, хранящему метаданные о текущем запросе. Этот объект должен передаваться непосредственно в функцию представления, а не функция представления должна обращаться к данным запроса из глобальной переменной. Это позволяет легко, чисто и просто тестировать представления, передавая «поддельные» объекты запросов.

Свободное соединение¶

Представление не должно заботиться о том, какую систему шаблонов использует разработчик - или даже о том, используется ли система шаблонов вообще.

Различия между GET и POST¶

GET и POST отличаются друг от друга; разработчики должны явно использовать то или другое. Система должна легко различать данные GET и POST.

Меньше кода¶

Кэш должен быть настолько быстрым, насколько это возможно. Следовательно, весь код фреймворка, окружающий бэкенд кэша, должен быть сведен к абсолютному минимуму, особенно для операций get().

Последовательность¶

API кэша должен обеспечивать согласованный интерфейс для различных бэкендов кэша.

Расширяемость¶

API кэша должен быть расширяемым на уровне приложения в зависимости от потребностей разработчика (например, см. Преобразование ключа кеша).