Как корректно описать PHP класс?

Question

[Талян]

Всем привет.

Как более правильно будет сделать модель для работы, например, с юзерами?

Вариант 1:

class Users {
protected $user_id;

public function by_id($id)
{
$this->user_id=$id;
return $this;
}

public function is_exist()
{
/*
$exist = здесь кусок кода, который смотрит - есть ли в БД юзер с айдишником $this->user_id
*/
return $exist ? true : false;
}
}

В таком случае я могу проверить существует ли пользователь:

$user=new Users();
$exist=$user->by_id(1)->is_exist();

Вариант 2:

class Users {
protected $user_id;

public function by_id($id)
{
$this->user_id=$id;
return $this;
}

public function is_exist($id=false)
{
$id=$id ? $id : $this->user_id;
/*
$exist = здесь кусок кода, который смотрит - есть ли в БД юзер с айдишником $id
*/
return $exist ? true : false;
}
}

В таком случае я могу проверить существует ли пользователь уже двумя способами:

$user=new Users();
$exist=$user->is_exist(1);
$exist2=$user->by_id(1)->is_exist();

Вопрос в том, правильно ли составлять класс таким образом, что одно и то же действие может выполняться двумя путями?

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

Я так же понимаю, что ответ может быть - "без разницы", но как делаете конкретно вы?

Comments

[Евгений Ромашкан]

Вы определитесь сначала что это за класс. Сущность? Репозиторий? Row Data Gateway?
Почему он хранит $id ?

[Талян]

Евгений Ромашкан, а, вот оно чё михалыч. Я про это и не знал. Оттуда у меня и вся каша.

У меня есть класс User с методами


И тут я понял, что чтобы добавить метод "user_delete($id)" - получается каша. У меня класс в основном занимается добычей инфы о текущем пользователе, а для работы с другими юзерами у меня класса нет.

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

[Талян]

BD_ l3ftoverZ!, это чтобы запутать врагов.)

[Victor Golovko]

Анатолий, @flapflapjack
Я бы сделал класс или метод, который возвращает объект юзера, если юзер сyществyет. Если не сyшествyет, то null

class User(){

public $name
 function __construct($data){
// set data
 }

   static public function get($id){
     $user = // from database
    if($user){
          return new self($user)
     }
      return null;
   }
}

$user = User::get(1);

[FanatPHP]

Я не понимаю смысла метода by_id($id). это просто такое написание стандартного setId()? Что он должн делать "по id"?

[Талян]

FanatPHP, да, именно - это setId(), но в Коми-Пермяцком стиле программирования по книге чукотского Атамана Ояйякудья с южных берегов Атлантиды.

Answer 1

[FanatPHP]

но потом мне стало совсем ничего не понятно - чего это у меня один и тот же класс будет всем подряд заниматься. Там и без того уже сборная солянка - и регистрация, и проверка текущих кукизов, а тут еще и ..

Именно в этом состоит разница между двумя основными архитектурами ORM - Active Record и Data Mapper.

Data Mapper разделяет работу с бд и бизнес-логику самого объекта. В итоге мы имеем два объекта - UserMapper и User. UserMapper занимается общением с базой - ищет в БД и возвращает инстанс объекта User, обновляет данные в БД, удаляет строку из БД. Класс же User реализует только бизнес-логику, ничего не зная о том, как его данные хранятся в БД.

Active Record же держит все в одном классе, то есть сам юзер ищет себя в базе, удаляет, и так далее.

Я думаю, сейчас настало время перейти к варианту Data Mapper.

Comments

[Талян]

Спасибо, очень доходчиво и просто. Так и сделаю.

тссс

Но потом :)

Answer 2

[Sergei Iamskoi]

class User {
  public static findById($id) {
    // Ищем в базе, и возвращаем как созданный объект:
    if ($dataFromDB) {
      return new self($dataFromDB);
      // Или что-то вроде того:
      $user = new self();
      $user->load($dataFromDB);
      return $user;
    }
    // Если не находим, то
    return null;
  }
}

Но лучше вместо своего велосипеда посмотреть на готовые ORM'ки и выбрать подходящую, раз с объектом из базы работаешь как с моделью.

Comments

[Талян]

Да, согласен с вами. В итоге сделаю так:

Допишу уже этот последний контроллер в проекте тяпляп, фиг с ним, не буду сейчас переделывать всё, если мне осталось три притопа два прихлопа и в продакшн.

А затем сразу начну изучать laravel, и во время знакомства с его структурой заодно углублюсь в ORM, и как писал выше Евгений Ромашкан почитаю как адекватные люди разделяют сущности, row data gateway и какой-то там репозиторий.

Заодно ещё ёлку уберу, а то до сих пор стоит.

[Евгений Ромашкан]

Анатолий, Советую всё же углубиться в "Совершенный код", "Рефакторинг"(Фаулера), PoEAA, "Чистый код" а Laravel просто потихоньку изучать параллельно )

Laravel не даст понимания как надо делать, лишь покажет пару способов как можно, и ещё добавит в инвентарь разработчка весьма сомнительных практик(Привет фасады, трейты, статика)

[Талян]

Евгений Ромашкан, оп, а вот за литературу спасибо отдельное.

Answer 3

[Северное Сияние]

Безсмысленно давать тебе какие-либо советы, пока не прочитаешь эту книгу и, в частности, Часть I. и Часть II раздел под названием "Глава 10. Архитектурные типовые решения источников данных"