Задать вопрос
@Alk90
php, mysql, jquery, css, html, api

Правильно ли такая ответственность классов?

Всем привет! Подскажите, правильно ли я распределяю ответственность классов в проекте, не наткнусь ли я потом на какие-то подводные камни или может я не вижу какой-то более элегантный способ?
У меня есть классы, которые преимущественно (бывают исключения) отвечают за работу с одной группой таблицей в БД. Например таблица пользователей и класс Users.
Вопрос в том, что по моей логике, класс Users не должен проверять поступившие данные. Он отвечает только за запись в таблицу или выборку из нее. т.е. если нужно удалять пользователя я вызываю метод $Users->delete($user_id), а все проверки вроде "а может ли текущий пользователь удалять других пользователей" или "может ли пользователь просматривать других пользователей", я выполняю до обращения в этот класс и его методам.
С одной стороны, классы остаются незащищенными, если вдруг какая-то проверка окажется дырявой или я забуду сделать проверку до вызова этого класса (но ведь всегда есть шанс чего-то дырявого, поэтому нужно быть внимательней).
С другой стороны, я могу использовать этот класс в разных контекстах (API или Сайт), все ошибки обрабатываются вне этого класса и их легко отдавать клиенту, особенно при разделении (API/сайт).
Пните пожалуйста в правильном направлении...
  • Вопрос задан
  • 118 просмотров
Подписаться 1 Простой Комментировать
Пригласить эксперта
Ответы на вопрос 3
Направление верное.
То что вы описываете как класс Users, это своего рода репозитарий, который знает как получить, записать, и удалить записи из соответствующей таблицы.

а все проверки вроде "а может ли текущий пользователь удалять других пользователей" или "может ли пользователь просматривать других пользователей"

Это зона ответственности другого класса или группы классов, системы доступа, как правило это RBAC.

классы остаются незащищенными, если вдруг какая-то проверка окажется дырявой ...

Это вполне нормальная ситуация, эта проблема решается написанием тестов.

Подробнее можно почитать про принципы SOLID, а именно про S - Single responsibility
Ответ написан
Комментировать
iNickolay
@iNickolay
В целом подход правильный.

я забуду сделать проверку до вызова этого класса
А для предотвращения этого используйте Dependency injection (Внедрение зависимостей)
Ответ написан
streetflush
@streetflush
почему бы не делать проверки именно в классе?
Если нужно удалить пользователя из 3х мест, проверки тоже писать 3 раза? (естественно если это не какая то уникальная проверка именно для конкретного случая).
Точно так же создается класс текущего пользователя, у которого проверяется, можно ли выполнить то или иное действие.
Конструктор класса должен проверять целостность данных.

Раз это API то все проверки должны быть на стороне сервера. А на клиенте, только первичная валидация, дабы не заставлять пользователя несколько раз отправлять форму. (обязательные поля, размер поля, правильность ввода e-mial)

Если хочется делать шарящиеся классы, То никто не мешает создать класс А с описанием полей. От него пронаследовать класс Б с валидацией и прочими плюшками. Класс А шарим, класс Б используем на сервере.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы