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

Question

[Алексей Коновалов]

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

Answer 1

[Евгений Бухарев]

Направление верное.
То что вы описываете как класс Users, это своего рода репозитарий, который знает как получить, записать, и удалить записи из соответствующей таблицы.

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

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

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

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

Подробнее можно почитать про принципы SOLID, а именно про S - Single responsibility

Answer 2

[Николай]

В целом подход правильный.

я забуду сделать проверку до вызова этого класса

А для предотвращения этого используйте Dependency injection (Внедрение зависимостей)

Comments

[Евгений Бухарев]

Можете привести пример реализации?
Так как Dependency injection к данной задаче никакого отношения не имеет

[Николай]

Евгений Бухарев, пример реализации DI? Посмотрите здесь.
Почему не имеет? В том же ларавел есть релизация - все проверки можно провести через репозиторий (в котором делаем проверку), который инъектится в контейнер. Что-то вроде

# request
class UserRequest extends FormRequest
{
  public function rules()
    {
      return [ ... ];
    }
}

#controller
class UserController extends Controller
{
  ...
  public function getUser(UserRequest $userRequest)
    {
      ...
    }
  ...
}

Answer 3

[Alex]

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

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

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