Спасибо за такой развернутый комментарий, думаю, это распространенная проблема, когда не используются отдельные Entity классы.
Мы в своем проекте, что бы отказаться от соблазна использовать методы queryset во всех слоях кроме сервисного, решили возвращать из сервисов и селекторов обычные Python коллекции, например листы. Мы основываемся на github.com/HackSoftware/Django-Styleguide с некоторыми изменениями и используем только обычные классы Serializer и APIView, также стараемся не использовать Relation филды, которые требуют передачи в них queryset. Валидация и поиск сущности в БД происходит в сервисах. Не всем данный подход подходит, так как приходится отказываться от некоторых удобств DRF. Также от использования методов модели это не защищает, и работают только договоренности.
Согласен с вами. Как раз такая схема описывается в последнем подходе в статье, только без репозитория.
Репозиторий отличный паттерн, но у него есть одна особенность, что бы он был настоящим и приносил плюсы, нам нужно использовать отдельные модели для сущностей, а не Django модели. Такой подход наиболее чистый и приносит массу плюсов, особенно, в приложениях, где много бизнес-логики и сложные бизнес-сущности, которые могут не укладываться в одну таблицу БД. Что-то подобное можно посмотреть тут github.com/dry-python/bookshelf
Но можно пойти на компромисс, если ваши бизнес-сущности не так сложны и всегда будут просто дублировать Django модели. Можно скрывать детали реализации доступа к данным за сервисным слоем или менеджером модели.
Придерживаться такому подходу:
использовать Django модели
в QuerySet описывать часто повторяющиеся фильтры, которые нужно часто комбинировать с другими условиями, например active() = filter(is_active=True)
использовать (писать) методы в Manager и вызывать их из сервисов или использовать только сервисный слой, например как у github.com/HackSoftware/Django-Styleguide сервисы и селекторы, для описания логики работы с данными
Можно посмотреть на github.com/cosmicpython/code/tree/appendix_django, github.com/dry-python/bookshelf или www.cosmicpython.com/book/chapter_02_repository.html
Мы в своем проекте, что бы отказаться от соблазна использовать методы queryset во всех слоях кроме сервисного, решили возвращать из сервисов и селекторов обычные Python коллекции, например листы. Мы основываемся на github.com/HackSoftware/Django-Styleguide с некоторыми изменениями и используем только обычные классы Serializer и APIView, также стараемся не использовать Relation филды, которые требуют передачи в них queryset. Валидация и поиск сущности в БД происходит в сервисах. Не всем данный подход подходит, так как приходится отказываться от некоторых удобств DRF. Также от использования методов модели это не защищает, и работают только договоренности.
Репозиторий отличный паттерн, но у него есть одна особенность, что бы он был настоящим и приносил плюсы, нам нужно использовать отдельные модели для сущностей, а не Django модели. Такой подход наиболее чистый и приносит массу плюсов, особенно, в приложениях, где много бизнес-логики и сложные бизнес-сущности, которые могут не укладываться в одну таблицу БД. Что-то подобное можно посмотреть тут github.com/dry-python/bookshelf
Но можно пойти на компромисс, если ваши бизнес-сущности не так сложны и всегда будут просто дублировать Django модели. Можно скрывать детали реализации доступа к данным за сервисным слоем или менеджером модели.
Придерживаться такому подходу: