Разделение бизнес-логики и модели
У меня есть этот вопрос, который беспокоит меня некоторое время. На первый взгляд это может показаться довольно простым вопросом, но четкого ответа, похоже, нет. Моя основа для того, чтобы задать этот вопрос, - это проект Python, который использует PostgreSQL через SQLAlchemy, но конкретный используемый язык и инструменты на самом деле не имеют значения.
Основной вопрос заключается в том, где поставить логику при использовании ORM? Конкретнее, какая логика должна входить в методы моих классов отображения?
Кажется, что есть несколько явных случаев, например, базовая проверка свойств, таких как минимальная длина или то, должен ли какой-либо адрес электронной почты принадлежать слою ORM (или даже самой базе данных).
Простой конкретный пример приведен по порядку, поэтому давайте предположим, что мы храним объекты пользователя. У пользователей есть адрес электронной почты (который является их уникальным идентификатором), пароль и идентификатор активации. Когда создается учетная запись, идентификатор активации назначается и отправляется пользователю по почте, который он затем использует для установки пароля.
Давайте посмотрим на пару сценариев:
- Пользователь создает учетную запись;
- Пользователь активирует учетную запись (т.е. устанавливает пароль).
Поэтому, когда пользователь создает учетную запись, нам нужно выполнить некоторую базовую проверку:
- Адрес электронной почты правильный => ORM;
- Адрес электронной почты уникальный => ORM или База данных (ограничение уникальности);
- Установить случайный идентификатор активации => ORM
Когда пользователь активирует свою учетную запись, я сталкиваюсь с проблемами. Я хотел бы проверить предоставленный пароль (например, достаточно долго? Достаточно цифр?), Но модель должна хранить пароль, используя некоторый алгоритм хеширования или шифрования. Кажется, есть два варианта:
1: Проверьте идентификатор активации и действительность пароля за пределами модели, хэшируйте пароль, затем установите хэш User.password, а идентификатор User.activation - ноль (чтобы указать активную учетную запись).
2. Создайте метод User.activate(активации_id, пароля), который проверяет все и соответственно устанавливает свойства User.password и User.activation_id.
3: Гибридная опция, сделайте опцию 1, но установите некоторый тип перехвата или события, когда Activation_id = null устанавливает пароль (если мы предполагаем, что можно установить либо идентификатор активации, либо пароль, тогда эта перехватка удовлетворяет базовому свойству согласованности: модель).
Я искал в Интернете, и есть некоторые источники, которые говорят об этой проблеме (включая некоторые вопросы SO), но ни один из них не отвечает на этот вопрос.