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

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

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

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

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

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

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

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

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

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

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

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

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
PHP Developer
YCLIENTS • Москва
от 200 000 до 350 000 ₽
PHP разработчик
Ведисофт • Екатеринбург
от 25 000 ₽
Midlle PHP developer (backend)
ИТЦ Аусферр • Магнитогорск
от 100 000 до 160 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Сверстать лейдинг на Joomla
24 апр. 2024, в 22:11
2000 руб./за проект
Консультация ПЛИС (FPGA)
24 апр. 2024, в 22:00
500 руб./в час
SEO сайта услуг
24 апр. 2024, в 21:49
10000 руб./за проект
Ещё заказы