Является ли для веб-сайта регистрация и авторизация частью абстракции пользователя?

Question

[Salvador2006]

Или же все-таки разумнее создать отдельные модели регистрации и авторизации?

Answer 1

[EugeneOZ]

Регистрация и авторизация существуют незвисимо от существования пользователя и друг от друга. Если над сущностью нужно производить какое-то действие, это действие должно производится не самой сущностью. Письма сами себя не отправляют, пользователи сами себе запись в базе данных не создают (они вообще не думают о БД). Имхо, разумнее разделить.

Answer 2

[TheHorse]

C другой стороны, регистрация и авторизация это то, что нужно только для пользователя. а по сему выделять ее как отдельную систему особого смысла нет.

Склоняюсь к тому, что эти системы должны быть подсистемами системы работы с пользователями.

Answer 3

[return]

Что регистрация, что авторизация — я бы их сделал статическими методами класса пользователя, которые в результате возвращают экземпляр этого класса.

Answer 4

[pletinsky]

Смотря какими сущностями Вы оперируете. Если есть сущность пользователь, то можно ли говорить о том, что он имеет разные режимы View — как авторизация и регистрация? Думаю в вашем случае врятли.

Регистрация это сущность, которая регистрирует (или создает) нового пользователя системы.
Авторизация — сущность, которая находит нужного пользователя системы по указанным идентификаторам и авторизует его.

Для них нужны разные модели. Просто так звезды сошлись в небе, что и у той и у другой сущности могут быть поля юзернейм и пароль например. Это вовсе не означает что они одни и те же. Не всегда ощущению, заставляющему Вас выделять какие то похожие части стоит доверять.
Делайте всегда по правильному.

В конце концов для авторизации далеко не всегда нужен юзернейм и пароль (авторизация через сторонние сервисы например).

Comments

[Salvador2006]

Спасибо за объяснение. Действительно, если разложить на MVC — иначе не получится.

[return]

Если есть несколько способов авторизации, то следует выделить общий интерфейс авторизации, который реализуют каждый из видов и этот способ передавать в статический метод авторизации юзера :) Модели не разные здесь, а одна — юзер.

[pletinsky]

По моему вы смешиваете терминологию ООП и MVC оперируя то понятиями классов и интерфейсов, то моделями.
Я говорю о концепции моделей. Как это будет реализовано на уровне классов — вопрос другого уровня — и тут возможны разные решения.
Хотя я у автора в тегах сейчас прочитал ООП — может быть он имел ввиду какие то другие модели — а я его не понял.

Так или иначе я бы сделал нормальные модели регистрации и авторизации, которые в первом случае создают объект пользователя, заполняют его и сохраняют в базу. А во втором случае находят объект пользователя в базе и проводят авторизацию.

А с какого перепугу класс пользователя должен сам отвечать за авторизацию в статическом методе, к тому же еще и принимать какой то объект интерфейса авторизации мне вообще не понятно. Принцип персональной ответственности это точно нарушает, даже если фактическая реализация авторизации в другом месте — просто за счет вызова. Да и вообще какие то извраты с ООП. Должно быть все проще.

Но я не отрицаю, что в каких то определенных ситуациях Ваше решение может быть вполне адекванто.

Answer 5

[alt-j]

Частью абстракции пользователя регистрация/авторизация точно не являются, ибо они могут создавать/изменять свойства сущности пользователя, но сами по себе не описывают никакю информацию о пользователе и не описывают никакие его действия (в том понимании, что не пользователь кого-то регистрирует/авторизирует, а он запрашивает эти действия у системы). Они всего лишь есть функционалом системы