Django models = бизнес-логика + доступ к данным? Или уровень доступа к данным должен быть отделен от модели django?

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

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

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

Есть ли действительно значение для разделения доступа к данным из моделей django или django уже предоставляет достаточный уровень доступа к данным с его ORM?

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

Ответ 1

После трех лет разработки Django я узнал следующее.

ORM - это уровень доступа. Больше ничего не нужно.

50% бизнес-логики входит в модель. Некоторые из них повторяются или усиливаются в Формах.

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

20% бизнес-логики завершается в других модулях приложения. Эти модули выше моделей и форм, но ниже функций представления, веб-служб RESTful и приложений из командной строки.

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

Очень важно, чтобы функции просмотра и веб-службы RESTful ничего не делали. Они максимально используют модели, формы и другие модули. Функции просмотра и веб-службы RESTful ограничены работой с капризами HTTP и различными форматами данных (JSON, HTML, XML, YAML, что угодно.)

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

Ответ 2

Ответ зависит от требований вашего приложения.

Для приложений, которые всегда будут использовать реляционные базы данных и могут быть связаны с определенным ORM, вам не нужно разделять доступ к данным и модели. Django ORM основан на шаблоне проектирования активной записи, который предполагает доступ к данным и модель вместе. Pro - простота, con - меньшая гибкость.

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

Я рекомендую книгу "Шаблоны архитектуры корпоративных приложений", написанную Мартином Фаулером для более подробной информации.