Чем проект отличается от приложения в терминологии фреймворка django

Обновлено: 04.07.2024

Я написал эту статью, чтобы рассказать в ней теорию, которая будет необходима для изучения Django REST Framework. Информация, изложенная в этой статье, не является исчерпывающей в данной теме и показывает историю развития веб-приложений лишь отчасти. Я просто постараюсь объяснить, почему этот фреймворк — часть естественной эволюции веб-технологий, и как при помощи него мы можем по-новому решать старые задачи веб-разработки.

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

Framework

Создавая приложение или любой другой программный продукт, мы хотим делать это быстро и качественно. Проще этого добиться, используя опыт и наработки других разработчиков, ведь многие задачи, которые мы встречаем в процессе работы, уже были кем-то решены. По сути, использование фреймворка позволяет сосредоточится на задачах бизнеса и не задумываться над техническими деталями там, где это возможно. Нужно отрисовать кнопку на сайте? Сделать авторизацию или сброс пароля? Сохранить данные пользователя из формы на сайте в базу данных? Для этого всё уже готово — бери и пользуйся!

Также важно понимать отличия Framework от библиотеки. Это похожие вещи. В обоих случаях в Python вы должны установить нужный пакет, импортировать и пользоваться им. Разница в том, что библиотеку в проекте вы используете там, где нужно, и так, как вы хотите, а фреймворк сам определяет способ разработки приложения, то есть не только предоставляет удобные инструменты разработки в виде вспомогательных функций и классов, но и непосредственно формирует архитектуру проекта, создает структуру кода, проще говоря, определяет путь, по которому вы будете создавать свое приложение.

Django

На сегодняшний день наиболее функциональным фреймворком для создания веб-приложений на языке Python является фреймворк Django. Django можно назвать MVC-фреймворком, так он реализует взаимодействие пользователя и системы:

Model (хранит данные пользователя)

View (отображает данные пользователя)

Controller (принимает изменения данных от пользователя).

Внутри Django эта терминология звучит немного иначе, но суть остается той же.

Разработка Django началась в 2003 году программистами Adrian Holovaty и Simon Willison, а публичный релиз состоялся в 2005 году. Функционал фреймворка хорошо отвечал требованиям в веб-разработке того времени. Он активно развивается и до сих пор. Хотя этот фреймворк и считается довольно крупным и многофункциональным, сам по себе он не мог удовлетворить все запросы веб-разработчиков. За время его существования сторонними разработчиками было создано огромное множество библиотек и фреймворков в качестве дополнений к Django, которые упрощают реализацию тех или иных задач: аутентификация через социальные сети, кеширование данных, хранение файлов в облаке и многое другое. Некоторые из дополнений со временем сами стали частью проекта Django, как это произошло с библиотекой South, управляющей миграциями базы данных. Но большинство дополнений так и остались независимыми пакетами. Одним из них и является Django REST Framework, при помощи которого мы можем создавать Web API на основе Django.

Web API

Сегодня сеть интернет построена по принципу Клиент-Серверного взаимодействия. Клиент посылает запрос — Сервер ему отвечает. В случае, когда между собой общаются два Сервера, мы условно называем Клиентом того, который отправил запрос и ожидает ответ, а Сервером будет тот, кто принимает запрос и отвечает не него. Взаимодействие браузеров и веб-сайтов (первые выступают в роли Клиента, а вторые в роли Сервера) традиционно делалось при помощи технологии html-рендеринга, именно так изначально это делал Django. Чтобы получить данные с веб-сайта, браузер отправляет запрос GET к Серверу. Сервер формирует ответ в виде html-страницы и передает ее браузеру. Так Сервер передает данные браузеру, но как браузер может передать данные Серверу? В этой самой html-странице Сервер заложил все необходимые веб-формы, заполнив которые, пользователь мог бы передать свои данные обратно на сервер. Когда вы ввели свои данные в форму на сайте, бразуер отправляет Серверу запрос POST, в котором содержатся ваши данные, а Сервер обрабатывает их и записывает в базу данных.

Все это отлично работало, но уже в середине нулевых такой подход перестал удовлетворять возрастающим требования в веб-разработке. Появлялись мобильные приложения, различные гаджеты с доступом в интернет, и для них уже не подходил стандартный способ html-рендеринга на сервере, ведь теперь каждому клиенту нужно было отрисовать данные по-своему. Постоянно увеличивалось взаимодействие серверов друг с другом, и html-формат уже не подходил. Для всех этих задач есть другой способ обмена данными — Web API. Смысл этого способа в том, что Сервер передает Клиенту не html-страницу, а непосредственно данные, никак не влияя на то, как эти данные будут в итоге представлены. Наиболее популярными форматами для передачи данных становятся XML и JSON. Таким образом Сервер полностью избавляется от задачи отрисовки данных. Какое-то время длился переходный период, когда разработчикам веб-приложений на Сервере приходилось поддерживать оба способа одновременно: html рендерился на Сервере для браузеров, а Web API использовался для мобильных приложений и интеграции с другими серверами. Понятно, что разработчикам приложений на Сервере приходилось делать двойную работу. Но в начале десятых ситуация стала меняться в пользу Web API. Этому способствовало молниеносное развитие инструментов на языке JavaScript, а также появление различных веб-фреймворков, одним из которых и является предмет данной статьи.

Браузерные приложения быстро научились отрисовывать веб-страницы самостоятельно, получая чистые данные с Сервера. Веб-приложения на сервере научились создавать API быстро и легко. Так сформировалась четкое разделение на Backend и Frontend разработку: тех, кто поддерживает приложение на Сервере, и тех, кто делает браузерные (клиентские) приложения. А Web API стал универсальным способом общения для Сервера и всех его клиентов (браузеров, мобильных приложений, других Серверов). Конечно, это не могло не привести к развитию стандартов в общении между системами. И Клиенту, и Серверу необходимо знать каким образом общаться с друг с другом, как передавать данные, как сообщать об ошибках. Разработчики всегда могли договориться о том, как взаимодействовать их приложениям, но наличие некоего стандарта в веб-разработке позволило бы эту задачу облегчить. И вот в начале десятых таким стандартом стала концепция REST.

В 2000 году Рой Филдинг написал докторскую диссертацию, где изложил концепцию REST. Там были рекомендации о том, как спроектировать Сервер, чтобы ему было удобно общаться с Клиентами. Выделю два главных принципа создания приложений в стиле REST:

Сервер не должен ничего знать о текущем состоянии Клиента. В запросе от Клиента должна быть вся необходимая информация для обработки этого запроса Сервером.
Каждый ресурс на Сервере должен иметь определенный Id, а также уникальный URL, по которому осуществляется доступ к этому ресурсу.

На данный момент мы можем найти фреймворк для создания приложений в стиле REST практически для каждого языка программирования, используемого в веб-разработке. Логика построения Web API на Сервере в этих фреймворках реализована одинаково.

У нас есть объект Кошка, и мы хотим создать запись о кошке на Сервере. Для этого мы отправляем запрос на сервер:

С данными в теле запроса

Плюс к этому запросу (и все другим) будет добавлен ключ аутентификации.

Ключ будет нужен, чтобы Сервер понял, что запрос происходит от авторизованного Клиента. Как мы помним из правила REST, каждый запрос от Клиента должен содержать всю необходимую информацию для обработки этого запроса Сервером. Здесь это правило работает: Сервер ничего не знает о Клиенте до запроса, но сам запрос содержит ключ авторизации, по которому Сервер определяет, что это за Клиент.

Сервер взял все поля, переданные клиентом, и добавил к ним поле Id. Здесь работает правило REST, согласно которому каждый ресурс должен иметь уникальный идентификатор и быть доступным по определенному URL. Сервер создал ресурс и вернул нам его Id.

Теперь мы можем получить данную запись по URL

Что, если Клиент хочет изменить созданные им данные на сервере?

С телом запроса:

Метод PUT используется для изменения данных. Номер 21 в URL говорит о том, какой именно объект нужно изменить. Теперь наша кошка имеет цвет “Black”.

С телом запроса:

Тут также мы указываем в Id объекта в URL, но передавать никаких данных в теле запроса для удаления объекта уже не требуется.

Django REST Framework

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

Тут я бы хотел процитировать слова Тома Кристи, создателя Django REST Framework.

“Неудивительно, что Django REST framework — это API фреймворк для Django. И он пытается заполнить все пробелы в том, как исторически был спроектирован веб-фреймворк Django”.

И действительно, пусть Django был спроектирован давно, он до сих отлично решает свои задачи. Однако с появлением новых требований в веб-разработке, отсутствие компонентов для создания Web API воспринимается как пробел.

Django REST framework способен этот пробел заполнить.

А мы уже заполнили все пробелы в теории и терминологии и готовы перейти к практике!

Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!

Я создаю свой первый настоящий веб-сайт с использованием Django, но я все еще пытаюсь понять разницу между проектом и приложением.

Например, мой веб-сайт - это спортивный новостной сайт, который будет содержать такие разделы, как статьи, рейтинговые таблицы и «расписание и результаты». Мой вопрос заключается в том, должен ли каждый из этих разделов находиться в отдельном приложении внутри целого проекта или нет? Какова лучшая практика в этой ситуации?

2 ответа

проект относится ко всему приложению и всем его частям.

приложение ссылается на подмодуль проекта. Он самодостаточен и не переплетается с другими приложениями в проекте, так что теоретически вы можете взять его и перенести в другой проект без каких-либо изменений. app обычно имеет свой собственный models.py (который на самом деле может быть пустым). Вы можете думать об этом как об отдельном модуле Python. Простой проект может иметь только одно приложение.

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

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

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

Приложения, направленные на привнесение модульности в ваш проект. Например, если вы создаете articles app , в идеале , вы можете использовать его в своем спортивном новостном проекте и повторно использовать в новом проекте, который требует его с минимальным изменением или без изменения его settings - скажем, проект блога, например.

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

Посмотрите структуру проекта Django. Это может дать вам некоторое представление о наилучшей практике организации вашего проекта Django.

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

проекты могут иметь многие приложения. Приложения могут быть разделены между многими проектами. Штраф.

Я не изобретаю блог или форум - Я не вижу, чтобы какая-либо часть моего продукта была повторно использована в любом контексте. Интуитивно я бы назвал это "приложением"."Я тогда сделайте всю мою работу в одной папке "app"?

если так. с точки зрения пространство имен, моя склонность использовать myproduct.myproduct , но, конечно, это не разрешено (но приложение, которое я создаю, - это мой проект, и мой проект-это приложение!). Поэтому я считаю, что, возможно, я должен подойти к Django, построив одно приложение на "значительную" модель, но я не знаю, где рисовать границы в моей схеме, чтобы разделить ее на приложения - у меня есть множество моделей с относительно сложными отношениями.

Я надеюсь, что есть общее решение для этого.

что остановить вас с помощью myproduct.myproduct ? То, что вам нужно для достижения этого, примерно состоит в следующем:

и так далее. Поможет ли, если я скажу views.py не назовут views.py ? При условии, что вы можете назвать на пути python функцию (обычно пакет.пакет.просмотр.имя_функции) он будет обработан. Просто. Все эти"проекты"/" приложения " - это просто пакеты python.

теперь, как вы должны это сделать? Или, скорее, как мне это сделать? Ну, если вы создаете значительную часть многоразовой функциональности, например, редактор разметки, это когда вы создаете "приложение верхнего уровня", которое может содержать widgets.py , fields.py , context_processors.py и т. д. - Все вещи, которые вы, возможно, захотите, чтобы импортировать.

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

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

однако, чтобы решить вашу фактическую проблему, да, ничто не говорит, что вы не можете работать с папкой проекта верхнего уровня. вот что делают приложения и вы можете сделать это если ты действительно хочешь. Однако я не склонен к этому по нескольким причинам:--11-->

настройка Django по умолчанию этого не делает.
часто я хочу создать основное приложение, поэтому я создаю его, обычно называемое website . Однако позже я, возможно, захочу разработать оригинальную функциональность только для этого сайта. Чтобы сделать его съемным (независимо от того, делаю я это или нет), я обычно создаю отдельный каталог. Это также означает, что я могу отказаться от указанной функциональности, просто разблокируя это пакет из конфигурации и удаление папки, а не сложное удаление правильных URL-адресов из глобального urls.py папка.
очень часто, даже когда я хочу сделать что-то независимое, ему нужно где-то жить, пока я забочусь о нем / делаю его независимым. В основном приведенный выше случай,но для вещей я намерен сделать общий.
моя папка верхнего уровня часто содержит несколько других вещей, включая, но не ограничиваясь сценариями wsgi, сценарии sql так далее.
Джанго управление расширениями полагаться на подкаталоги. Поэтому имеет смысл называть пакеты соответствующим образом.

короче говоря, причина, по которой существует конвенция, такая же, как и любая другая конвенция - это помогает, когда дело доходит до других, работающих с вашим проектом. Если я увижу fields.py я сразу ожидаю, что код в нем будет подклассом поля django, тогда как если я вижу inputtypes.py я, возможно, не так ясно, что это значит, не глядя на него.

как только вы закончите использовать startproject и startapp , ничто не мешает вам объединить "проект" и "приложение" в одном пакете Python. Проект на самом деле не более чем settings модуль, и приложение на самом деле не более чем models модуль-все остальное необязательно.

для небольших сайтов вполне разумно иметь что-то вроде:

попробуйте ответить на вопрос: "Что делает мой заявление сделать?". Если вы не можете ответить в одном предложении, тогда, возможно, вы сможете разбить его на несколько приложений с чистого логика.

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

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

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

если это так. с точки зрения проекта Django.пространство имен приложений, моя склонность к usemyproduct.myproduct, но, конечно, это не допускается

нет ничего, как не допускается. Это ваш проект, никто вас не ограничивает. Желательно сохранить разумное имя.

Я не вижу, чтобы какая-либо часть моего продукта была повторно использована в любом контексте. Интуитивно я бы назвал это "приложением"."Делаю ли я тогда всю свою работу в одном" приложении" папка?

В общем проекте django есть много приложений (приложений contrib), которые действительно используются в каждом проекте.

предположим, что ваш проект выполняет только одну задачу и имеет только одно приложение (я называю его main поскольку thethe проект вращается вокруг него и вряд ли подключается). Этот проект тоже использует некоторые другие приложения в целом.

теперь, если вы говорите, что ваш проект используя только одно приложение ( INSTALLED_APPS='myproduct' ) Итак, что такое использование project определение проект как project.app , Я думаю, вы должны учесть некоторые моменты:

есть много других вещей, которые обрабатывает код, отличный от приложения в проекте (базовые статические файлы, базовые шаблоны, настройки. т. е. предоставляет базу).
в общем проекте.app app app approach django автоматически определяет схему sql из моделей.
ваш проект будет намного проще построить с помощью обычного подхода.
вы можете определить некоторые разные имена для URL, представлений и других файлов, как вы хотите, но я не вижу необходимости.
вам может потребоваться добавить некоторые приложения в будущем, которые будут очень легко с обычными проектами django, которые в противном случае могут стать одинаково или более трудными и утомительными.

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

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

представьте, что вы создаете big динамический веб-приложения на основе JavaScript.

вы можете создать затем в приложении django с именем e.g "FrontEnd"

затем вы создаете некоторые бэкэнд-приложения. Например, приложение с именем "комментарии", которое будет хранить комментарии пользователей. И приложение "комментарии" ничего не будет отображать само по себе. Это будет просто API для AJAX-запросов вашего динамический JS сайт.

таким образом, вы всегда можете повторно использовать приложение "комментарии". Вы можете сделать его открытым исходным кодом, не открывая источник всего проекта. А ты держи себя в чистоте!--3-->логика вашего проект.

У меня довольно сложный «продукт», который я готовлю к сборке с использованием Django. Я собираюсь избегать использования терминов «проект» и «приложение» в этом контексте, потому что мне не ясно их конкретное значение в Django.

Проекты могут иметь много приложений. Приложения могут быть использованы многими проектами. Хорошо.

Я не заново изобретаю блог или форум - я не вижу, чтобы какая-то часть моего продукта могла быть повторно использована в каком-либо контексте. Интуитивно я бы назвал это «приложение». Затем я делаю всю свою работу в одной папке "приложения"?

Если так . с точки зрения project.app пространства имен Django , я склонен использовать myproduct.myproduct , но, конечно, это не разрешено (но приложение, которое я создаю, - это мой проект, а мой проект - приложение!). Поэтому я склонен полагать, что, возможно, я должен подходить к Django, создавая одно приложение для «значимой» модели, но я не знаю, где провести границы в моей схеме, чтобы разделить ее на приложения - у меня много моделей с относительно сложными отношениями.

Я надеюсь, что есть общее решение для этого .

Что мешает вам использовать myproduct.myproduct ? То, что вам нужно для этого, примерно состоит в следующем:

и так далее. Поможет ли это, если я скажу, что мне views.py не нужно звонить views.py ? При условии, что вы можете назвать в пути python функцию (обычно package.package.views.function_name), с которой она будет обрабатываться. Просто как тот. Все эти "проекты" / "приложения" просто пакеты Python.

Теперь, как ты должен это сделать? Или, скорее, как я могу это сделать? Ну, если вы создаете значительную часть многоразовой функциональности, как , скажем , редактор разметки, это при создании «приложения верхнего уровня» , которые могут содержать widgets.py , fields.py , и context_processors.py т.д. - все вещи , которые вы могли бы хотеть импорт.

Точно так же, если вы можете создать что-то вроде блога в формате, который является довольно общим для установок, вы можете обернуть его в приложении, с его собственным шаблоном, папкой статического содержимого и т. Д., И настроить экземпляр проекта django для использования этого содержание приложения.

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

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

Читайте также: