Концептуальные подходы

В этом документе объясняются некоторые фундаментальные концепции, которые разработчики Django использовали при построении системы. Его цель - объяснить прошлое и направить будущее.

Обзор

Слабая связь

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

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

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

Меньше кода

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

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

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

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

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

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

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

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

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

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

Модели

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

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

Включите любую релевантную логику домена

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

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

API базы данных

Основные цели API базы данных:

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

Операторы SQL должны выполняться как можно реже, а операторы должны быть оптимизированы внутри.

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

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

Короткий, но мощный синтаксис

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

Присоединения должны выполняться автоматически, в фоновом режиме, если применимо.

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

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

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

Дизайн URL

Слабая связь

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

Это философия Jig Legacy .

Отделение от HTML

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

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

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

Уверенность в компетентности дизайнера

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

Естественная обработка пространств

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

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

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

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

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

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

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

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

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

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

Просмотры

Простота

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

Использование объектов запроса

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

Слабая связь

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

Разница между GET и POST

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

Инфраструктура кеширования

Основными целями инфраструктуры кеширования Django являются:

Меньше кода

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

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

Cache API стремится предоставить унифицированный интерфейс, который применяется к различным механизмам кеширования.

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

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

Copyright ©2021 All rights reserved