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

Question

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

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

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

Действительно ли целесообразно отделять доступ к данным от моделей django или django уже обеспечивает достаточный уровень доступа к данным с помощью ORM?

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

Answer 1

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

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

50% бизнес-логики идет в модели. Часть этого повторяется или усиливается в формах.

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

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

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

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

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

Answer 2

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

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

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

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