Правильно ли использование статичных методов в таком контексте?

Question

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

Всем привет!
У меня есть класс Users, который работает с БД только стаблицей users и связанными с ней, например friends. Класс имеет методы:

• get() - получить всех пользователей
  
• getById($id) - получить пользователя по ID
  
• getByIds($ids) - получить несколько пользователей по их ID
  
• search($q) - поиск пользователя по тексту
  

Ну и вспомогательные методы вроде limits(), sorts() и т.д.

Но в неком модуле, например модуль комментариев. Мне нужно обновить рейтинг пользователя.
Правильным ли будет создать статичный метод Users::UpdateRating($rating, $user_id);, с помощью которого я буду в любом нужном мне модуле вызывать его для изменения рейтинга пользователя?

Answer 1

[Stanislav]

Нет, конечно. Здесь не уместен статический метод. Вам же в любом случае придется найти пользователя, а уже затем обновить ему рейтинг.

Я не знаю как ваш Users устроен, но в общем и упрощенном случае следует сделать так:

class Users extends Model {
    ...
    protected $id;
    protected $name;
    protected $password;
    ...
    public function getById($id)
    {
        // Т.е. мы возвращаем эту же модель Users, но уже с данными конкретной записи из БД
        return $this->where('id', $id); 
    }

    public function rating()
    {
        // Возвращает модель рейтинга данного пользователя
        // Саму модель рейтинга здесь хардкожу, но в реальности лучше что-то более гибкое придумать
        return RatingModel::where('user_id', $this->id); 
    }

    public function updateRating($rating)
    {
        // обновляем рейтинг данного пользователя
        $this->rating()->update(['rating'=>$rating]);
    }


    ...
}

Таким образом получается гибкая и понятная система. В самом коде используется так:

$user = (new Users)->getById(1);
$user->updateRating(200);

Статику следует использовать тогда, когда это оправданно и необходимо, и когда без неё нельзя.

Comments

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

Спасибо!
Пользуясь случаем хотел бы спросить... Получается, при таком юзере, когда модель рейтинга отдельно с юзером, при получении списка пользователей, запросы на получение рейтинга также нужно делать отдельно, через собственную модель?

[Stanislav]

Алексей Коновалов,
В целом - да, но это будет не очень эффективно, т.к. у вас будет 2 запроса для получения рейтинга и 3 на его обновление через пользователя, а желательно эти запросы объединить в 2.

А что вы используете в качестве движка БД? Чистый PDO или какую-то ORM? Если вы велосипед хотите написать для себя - то нужно делать импровизированный querry builder, и это не самая простая задача, вот пример на коленке очень небольшой части требуемого функционала такой модели:

abstract class DatabaseModel {
    ....
    public function select()
    {
        $this->query_string = htmlspecialchars("SELECT * FROM ".$this->tableName);
    }
    
    public function find($id)
    {
        return $this->where('id',$id)->get();
    }
    
    // Следует еще использовать магию для этого метода, чтобы была возможность вызывать его статически
    // но это тоже опустим
    public function where($column, $value, $condition = "=") 
    {
        $this->query_string .= htmlspecialchars($this->select() . "WHERE " . $this->tableName.".".$column . 
$condition . $value);
    }
    
    public function update(...) {...}
    public function delete(...) {...}
    ...

    public function get()
    {
        // сейчас возвращаем массив, но нужно в реальном решении возвращать эту же модель,
        // но где уже все свойства заполнены данными из БД, опущу этот процесс для простоты.
        // Если действительно хотите реализовать это - используйте для удобство магию (сеттеры),
        // чтобы доступ к свойствам был удобен и они были динамическими
        return PDO::exec($this->query_string)->fetchAll();
    }
    ....
}

Это грубый набросок на коленке, он скорее всего не безопасный и не рабочий.

Таким образом непосредственно выполняться запрос будет только на команду get(), что позволит сделать нечто такое:

class Users extends DatabaseModel {
    ...
    public function getById($id)
    {
        // Этот метод нам вообще не нужен теперь, пользователя можно будет просто получить.
        // При реализации нормальной get() - получим модель Users конкретного пользователя
    }

    public function rating()
    {
        // Возвращает модель рейтинга данного пользователя
        return Rating::where('user_id', $this->id)->get(); 
    }
    ...
}

Тогда в итоге:

// При нашей самопальной реализации это будет жрать 3 запроса: 1)поиск user 2) поиск rating 3) update
User::find(123)->rating()->update(['rating'=>200]);

//также и в обратную сторону, но это будет жрать 1 запрос 1)поиск rating и update
Rating::where('user_id',123)->update(['rating'=>200]);

Это просто набросок и реализовать это всё новичку будет достаточно сложно. Если интересно - нагуглите любой урок по созданию самопальной ORM с PDO и там подробнее объяснят что к чему и как.

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

А что вы используете в качестве движка БД? Чистый PDO или какую-то ORM?

Я написал велосипед, похожий на класс DatabaseModel, который описали Вы.
Но далее у меня все координально отличается... Моя логика была такая... Пользователю рейтинг нужно обновлять в десятки раз реже чем получать список или одного пользователя. А учитывая то, что пользователь выводится почти везде с рейтингом (комментарии, посты, новости, друзья и т.д.) то, это будет тысяча к одному...
Поэтому 2 запроса мне и сейчас кажется много... А ведь сколько еще нужно приджойнить других таблиц, которые связаны с пользователем.
Вот примерно так выглядит мой класс юзеров на примере получения одного пользователя:

class Users extends DBModel {

    public function getById(int $id){

        // указываем какие поля нам нужны и какие таблицы нужно приджойнить
        // на самом деле имеется метод setFields, где я указываю только поля id,login,rating
        // А метод уже берет массив, в котором описаны правила, какие названия указанных полей соответствуют реальным в БД
        // и какие для этого поля нужно присоеденить таблицу
        // поэтому не приходится в каждом методе прописывать $this->join и $this->select,
        // а достаточно выполнить $this->setFields("id, login, rating")
        $this->select("u.`id`, u.`login`, r.`rating`");
	    $this->join("LEFT JOIN `users_rating` r ON r.`user_id` = u.`id`");
	    $this->where("`id` = {$id}");
	    
        //Возвращаем уже готовый объект
        return $this->createObject($this->exec());

	}

	/**
	 * Метод создает объект пользователя на основе полученных из БД полей
	 * @param $row
	 * @return UserEntity
	 */
	private function createObject($row){
		$object = new UserEntity;
		
		if($this->isField("id")) $object->setId($row['id']);
		if($this->isField("login")) $object->setLogin($row['login']);
		//... и так для всех возможных полей
        // Да, если я добавлю поле в таблицу, мне нужно его будет прописать
        // тут, создать метод в UserEntity и создать правило для setFields.
		
		return $object;
	}

	public function get(){
		// Получение списка пользователей
	}

	public function getByIds(array $ids){
		// получение пользователей по ID
	}

	public function search(string $q){
		// поиск по пользователям
	}

}

Answer 2

[index0h]

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

Answer 3

[kenny_gomel]

Я бы порекомендовал тогда ожидать на входе Users::UpdateRating одно значение рейтинга и массив Id юзеров

Comments

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

На тот случай, если захочется обновить рейтинг нескольким юзерам?
А в целом это нормальное (целевое) использование статических методов?

[kenny_gomel]

Алексей Коновалов, именно, но это по желанию, и в зависимости от целей

Вообще нормально, но зачем? Лучше определить публичный метод, и вызывать его из модели, передавая только рейтинг.
В общем если не планируете массово менять рейтинг юзеров, обычный публичный метод ваше всё :)