Какой должна быть структура каталогов для REST API в Django? - PullRequest
Новая
       10

Какой должна быть структура каталогов для REST API в Django?

0 голосов
/ 18 января 2019

Я начинаю с разработки REST API с использованием инфраструктуры Djano. Ранее я много работал со средами, связанными с Java, в частности с SpringBoot.

Если я возьму пример API REST в среде на основе Java, ниже приведена структура каталогов, которую я в основном использовал:

enter image description here

Так что в основном это что-то вроде MVC Design Pattern . Кроме того, в java каждый класс в основном записывается в новый файл, однако учебники, которые я изучал, пишут несколько классов в одном файле. Является ли это наилучшей практикой для Django?

Также я вижу, что в Django мы создаем проект, а затем внутри него мы создаем приложение. Это приложение эквивалентно пакету в Java?

Кроме того, в SpringBoot и других связанных с Java инфраструктурах мы обычно следуем нисходящему подходу, когда Контроллер получает вызов, который затем передается в Сервис, где находится вся бизнес-логика, которая затем вызывает DAO (Репозиторий) для CRUD. и соответствующий результат передается из DAO в службу обратно в контроллер, который генерирует отформатированный ответ.

В Джанго я видел только то, что вся логика написана на представлениях, называющих Модель для CRUD. Разве мы здесь не следуем твердым принципам?

Если я возьму пример системы управления библиотекой, как можно спроектировать ее на основе инфраструктуры Django?

1 Ответ

0 голосов
/ 18 января 2019

Это отличный вопрос, но я не уверен, что StackOverflow - правильное место, чтобы задать его, так как нет однозначного ответа.Тем не менее, я пытаюсь дать ему шанс.

Django также следует шаблону проектирования MVC, но наименование немного другое.

  • Модели Django -> Модели MVC
  • Представления Django -> Контроллеры MVC
  • Шаблоны Django -> Представления MVC

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

  • толстые модели: вы помещаете всю свою бизнес-логику в службы
  • : у вас есть отдельные модули, содержащие методы / классы для вашей бизнес-логики

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

Эквивалентом DAO в Django, вероятно, является Django ORM.Обратите внимание, что это действительно только уровень абстракции для поддерживаемых реляционных баз данных.Если вы хотите использовать другой источник данных, такой как NoSQL DB или REST API, вы должны свернуть свое собственное решение или искать сторонние пакеты.

Java может иметь только один открытый класс на файл, и они должны иметьодно и то же имяВ Python такого ограничения нет, поэтому рекомендуется использовать несколько классов на файл (файлы .py называются модулями).Если модуль / файл становится слишком большим, вы можете превратить его в пакет (каталог с файлом __init__.py), содержащий несколько модулей (и / или подпакетов).

Различие между приложением и проектомможет сбить с толку, поэтому я написал целую статью о схеме именования Django .Приложение Django представляет собой пакет Python, но обычно они организованы по доменам.Например, в системе управления библиотекой ваш проект library может иметь приложение catalogue для управления запасами и приложение checkout для управления процессом извлечения книг.

Наконец, если выЯ специально рекомендую взглянуть на Django REST Framework .

.
...