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

Слабое сцепление ¶

Фундаментальная цель стека Django - слабая связь и тесная связность . Различные уровни структуры не должны «знать» друг о друге без крайней необходимости.

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

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

Меньше кода ¶

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

Быстрая разработка ¶

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

Не повторяйся (СУХОЙ) ¶

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

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

Явное лучше, чем неявное ¶

Это основной принцип 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 должна упростить хранение этих элементов в одном месте, исключая дублирование кода.

Это философия наследования шаблонов .

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

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

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

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

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

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

Очевидно, относитесь к пробелам ¶

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

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

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

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

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

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

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

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

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

Это философия, лежащая в основе настраиваемых тегов и фильтров шаблонов.

Простота ¶

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

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

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

Слабое сцепление ¶

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

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

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

Меньше кода ¶

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

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

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

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

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