Как получать один объект в разных запросах?

Question

[Алексей]

Всем привет! Я совсем запутался в этом ООП.
Мне нужно создать список объектов например user. Каждый объект будет содержать в себе поля (их много. Имя фамилия, адрес, фото, логин, количество постов, подписчиков и т.д.).
Получить такой список объектов из базы просто... Делаем запрос:
SELECT * FROM `users`
Мы получим список объектов users. Вроде профит, НО...

Если в другом запросе нам нужно вывести пользователей "лайкнувших" пост. Опять выполняем запрос:

SELECT u.* 
FROM `likes` lk 
INNER JOIN `users` u ON u.`id` = lk.`user_id`
WHERE lk.`post_id` = 1775

Мы опять получили список тех же объектов, но фактически после второго запроса мы будем создавать объекты уже заново в куске кода, который не подойдет для первого запроса. Получается, что и в том и другом случае мы можем создать разные объекты, если будем указывать разные поля в запросе. Красиво получилось бы так:
И в первом и во втором запросе получаем только поле ID пользователя, а потом передаем эти ID в метод getUsers, который выводит объекты users по единому правилу. А тот в свою очередь делает запрос в БД, в котором во WHERE IN() указывает полученные ID нужных пользователей. Но в этом случае получается два запроса, причем второй будет содержать кучу ID-шников в IN(). Что явно плохо...

Вот вопрос, как сделать так, чтобы можно было использовать единый метод для получения объектов user?
Или все-таки это правильно, создавать новый объект в каждом запросе, ведь в приложении встречаются не только запросы по лайкнувшим пост пользователям, но и подписчики, поиск по по пользователям, список недавно зарегистрированных пользователей и так далее... Выходит для каждого такого запроса нужно создавать свои объекты users.

Прошу прощение за такое изложение вопроса, надеюсь я нормально объяснил... может устал за целый день...

Comments

[DTX]

Мы опять получили список тех же объектов, но фактически после второго запроса мы будем создавать объекты уже заново в куске кода, который не подойдет для первого запроса

Какие объекты создавать? В каком куске кода? Почему не подойдёт? Если поля выборки одни и те же, то пожалуйста, используйте один код для разных запросов.

И я не понял, как связано ООП со скулем.

[Алексей]

DTX, Спасибо за ответ, чтобы мне не писать везде одно и тоже, гляньте пожалуйста мой ответ Decadal-у

Answer 1

[Decadal]

Давайте начнем с того, что база данных это не про ООП. База данных это то, что выросло из примитивных файликов на жёстком диске, куда выплёвывается всякая разная информация, родившаяся во время работы с программой.
БД ставит себе цель работать очень быстро с гигантскими объемами данных. БД имеет свою фишечку по красоте собственного устройства, называется нормализацией.
Если вы будете пришивать ко всему, что увидите, ООП, очень скоро заметите что время разработки просто упрется в бесконечность.

А теперь касательно вашего примера: у вас есть класс который называется юзер. В него попадают данные после запроса всех юзеров - и он с ними работает. А потом в него попадают данные после запроса юзеров, поставивших лайки - он работает и с ними.
Все. Это потолок, шедевр, ООП тут сделало свою работу. Можете кодить спокойно дальше.
Пока не узнали что модель юзера может меняться в зависимости от ситуации, и где-то вам понадобится модель юзера с моделью аватарки внутри, а где-то - с моделью аватарки и ещё и моделью токена...
Пока что все хорошо.

Comments

[Алексей]

Ну то, что БД никак не связана с ООП это понятно, я просто опустил это в описании. Понятно, что после запроса мы обрабатываем полученные данные в каком-то классе, работающем с пользователями.
Но как раз тут у меня тупик... Если поля будут разными в разных запросах, то в классе Users мне нужно просто делать проверку на существование того или иного поля? И на сколько я понял по вашему ответу, нужно так и создавать методы со своими запросами к БД в одном классе Users?
т.е. класс получится примерно таким?

class Users{

   private $users = array(); //записываем данные о полученных юзерах со всех методов

   // получаем список лайкнувших пост
   function getUsersLiked($post_id){
      // запрос в БД
   }

   // получаем список всех юзеров
   function getAllUsers(){
      // запрос к БД
   }

  // получаем список подписчиков какого-то конкретного юзера
  fucntion getFollowers($owner_id){
     // запрос к БД
  }

  // ..... и так далее для каждого случая

  function showUsers(){
     // Выводим все, что есть в массиве $this->users
     // При этом проверяя существование каждого поля, если его нет - просто не выводим
  }

  // .... ну и дальше другие методы вроде соединения каких-то отдельных полей
  // к этим методам будет обращаться метод showUsers()
  function getLocation($user_id){
     return $this->users[$user_id]['country_name'].', '.$this->user[$user_id]['city_name'];
  }

}

Я правильно понял?

[Decadal]

Евгений

Ну, окей, тогда немного про ооп.
Итак: каждый объект класса User (заметьте, не Users) имеет first_name, last_name и прочее. Он у нас называется моделью, а у вас в программе он представлен элементом массива $_users (приватного поля класса Users)
Что вам нужно знать:
1) класс User не знает о существовании каких-либо других полей. Он знает только о своих, и будет принимать только свои, только конкретные first_name, last_name.
2) класс Users, судя по названию, должен отвечать за хранение списка пользователей (т.е. массива объектов User). А значит, он должен умееть добавлять юзеров ( метод addUser ), удалять их (... ну вы поняли), чтобы быть полноценным контейнером. И вот тут самое интересное: именно в метод addUser извне и будут попадать все нужные поля для создания юзера, и тут же должна быть вся проверка, какое поле есть, какого нет, как с этим жить и тд).
3) вам бы вообще не стоило совмещать выгрузку из базы и хранение данных в одном и том же классе, но это другая история, называемая проблемой ORM.

И на сколько я понял по вашему ответу, нужно так и создавать методы со своими запросами к БД в одном классе Users?
т.е. класс получится примерно таким?

а теперь об этом.

// получаем список лайкнувших пост
function getUsersLiked($post_id){
// запрос в БД
}

неправильно. Это пост знает о тех, кто его лайкнул. Эта функция должна быть в классе Posts. User не должен знать о таких вещах, кого он там лайкает. Простая аналогия: вы покупаете что-то в магазине. Это не вы должны запомнить кассира, которому даёте карточку, а кассир должен запомнить, с чьей карточки он принял оплату, потому что ему же потом отчитываться. Так же и посту потом "отчитываться", какие юзеры его лайкнули.

function showUsers(){
// Выводим все, что есть в массиве $this->users
// При этом проверяя существование каждого поля, если его нет - просто не выводим
}
// получаем список всех юзеров
function getAllUsers(){
// запрос к БД
}

Избыточные операции. Мм... на данном этапе всё чем могу помочь - сказать что getAllUsers по задумке должен возвращать то же, что и showUsers, т.е. хотя бы прятать от всего мира тот факт что он загружает данные из базы, и выплевывать уже готовые, обработанные модельки юзеров. Пример:

function getAllUsers() {
$usersRecords = $this->dbConnection->selectAllFromUsersTableEtc(); 
for ($i = 0, $size = count($usersRecords); $i < $size; $i++ ) 
{
$currentRec = $usersRecords[$i];
//that's what i mean when said 'preparing', обработка 
$location = [ //or $this->formateLoc($currentRec);
"city" => $currentRec["city_name"], 
"country" => $currentRec["country_name"]
];
$this->addUser($currentRec['id'], $currentRec["first_name"], $currentRec["last_name"], $location, //...); 
}
}

function addUser($id, $firstName, $lastName, $locObject) {
//check for values
$user = new User($id); //эх а вот был бы у вас этот класс, а не просто массив...
$user->firstName = $firstName; 
$user->lastName = $lastName; 
if(! isset($locObject["country"]) ) {
throw new \Exception("Location object is invalid");
} 
$user->setLocation($locObject);
$this->users[$id] = $user; 
}

И тогда у вас не будет никаких function getLocation($user_id) у контейнера. Потому что это неправильно. Контейнер должен видеть в юзерах цельные куски инфы, а не выдавать вам фрагмент инфы по одному юзеру. Или отдал всего юзера или ничего.

[Алексей]

Decadal, Ужас, чем дальше в лес, тем больше дров. Но мы как раз и подошли к моему вопросу на примере кода выше, уделите пожалуйста мне еще немного времени...
Получается в методе selectAllFromUsersTableEtc() мы получаем список всех пользователей?
Но вот смотрите, например создаю я в классе Posts метод GetUsersLiked(), где получим данные о лайкнувших, там нам нужны только поля (id, firstName, lastName и, предположим, наш location). Значит прямо в методе GetUsersLiked() делаем запрос в БД (Я слышал, что требуется разделять запросы к БД от методов, но мне так проще описать пример, но к тому же я не совсем понимаю зачем их разделять, на практике не потребовалось ни разу, а код получается разбросанным). В общем получается примерно такой класс Posts

class Posts{
	
	public $db;
	private $users = array();
	
	function __construct($db){
		$this->db = $db;
	}

	function GetUsersLiked($post_id){
		
		$res = $this->db->query("SELECT u.`id`, u.`firstName`, u.`lastName`, u.`country_name`, u.`city_name`
			FROM `likes_posts` lk
			INNER_JOIN `users` u ON u.`id` = lk.`user_id`
			WHERE lk.`post_id` = {$post_id}");

		while($row = $res->fetch_assoc()){
			// теперь добавляем все полученные результаты в класс User, который и слепит нам объект
			
			/*==== вот этот код у нас повторяется с классом UserS ====*/
			// полагаю, тогда нам нужно вызывать метод addUser() из класса Users, а не сразу обращаться к классу User? 
			$user = new User($row['id']);
			
			$user->firstName = $row['firstName'];
			$user->lastName  = $row['lastName'];
			/*============*/

			/*===== Вот тут опять повторяется код, поэтому я и решил, что нужно создать отдельный метод в классе UserS ====*/
			$locObject = [
				"city" => $row["city_name"], 
				"country" => $row["country_name"]
			];
			
			$user->setLocation($locObject);
			/*===========*/
			
			// А тут опять что-то не то, в итоге мы все равно создаем массив юзеров, как и у меня в примере выше
			$this->users[$id] = $user;		
		}
	}
}

И вот тут как раз по моему вопросу.... Что теперь делать с этим массивом $this->users?
Опять его кидать в какой-то класс, который снова будет пробегать по массиву и выводить нужные данные о каждом пользователе? Причем в этом классе прийдется опять создать разные методы, например для вывода лайкнувших (тут ведь только 4 поля нужны), для вывода друзей (тут нужно больше полей) и так далее...

[Decadal]

Евгений,

а код получается разбросанным.

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

Значит прямо в методе GetUsersLiked() делаем запрос в БД

и на этом моменте резко выдыхаем, возвращаем все что нам вернула база и перестаём обрабатывать юзера в классе Posts. Никаких дальнейших действий. Никаких юзеров в private поле. Просто остановитесь на этом. Объясню ниже.

Получается в методе selectAllFromUsersTableEtc() мы получаем список всех пользователей?

да. Но вы им одним не обойдётесь.
Выбрать всех пользователей, но с аватарками (хранятся в таблице files с полями file_ext, file_name)?
Выбрать всех пользователей, но с инфой об их персональных данных (которым стоит храниться отдельно)?
Выбрать всех пользователей, но вместо first_name и last_name сделать колонку full_name?
Вы замечаете, что желание из всех запросов сотворить модель new User($результат, $очередного, $безумного, $запроса); выносит мозг?
А главное - всё это вместе взятое остаётся тем самым юзером, просто упорно не лезет в то ООП, которое вы пытаетесь воссоздать, ну не может везде и всюду быть нужна инфа только из одной таблицы users, или только из posts. Это не удовлетворяет бизнес-потребностям (читайте: не устроит заказчика).

Вот для этого нужно разделять "место_где_вы_делаете_запросы" от "место_где_вы_обрабатываете_результат".
Взгляните на код:

class UserQueries {
   public function getUserWithAvatar($ids = []) {
      $result = $this->db
->createCommand("SELECT u.id, u.name, f.name AS avatar_name from users u inner join files f ON f.id = u.avatar_id")->execute();
       //делаем кучу правильных обработок, учитываем что 
//если $ids не пустой то нужно сформировать WHERE id IN ();
       // возможно кешируем запрос, если он будет часто браться 
      return $result; 
   }
}

class UsersController() 
{ 
//список всех юзеров с аватарками
   public function actionIndex() {
      $uq = new UserQueries();
 // сырая инфа из базы!
      $usersList = $uq->getUserWithAvatar(); 
// пути разошлись! вы можете 1) создать контейнер со всеми чисто-аватарками 
//и контейнер с чисто-юзерами по отдельности 
//2) создать контейнер с UsersWithAvatar - да-да, эта фиговина будет хранить модели пользователей с аватарками! 
// только прочтите правильно: модели (пользователей с аватарками)
// а не модели пользователей и модели аватарок.
//"Так это же дублирование..? ведь есть Users, какой еще UsersWithAvatar??" - можете спросить вы, но я отвечу - 
//светлые головы изобрели наследование для таких моментов, и UsersWithAvatar just extends UsersContainer

      return new UserWithAvatarsContainer($usersList); 
      //или, как в фреймворках делается: 
      // return $this->render('index', [ 'dataProvider' => $userWithAvProvider ] );     
   }
}
// какая-нибудь вьюха
//($container это наш $userWithAvContainer)
$usersWithAv = $container->getAll(/*обычно это делается с пагинацией, а то от 124123242 юзеров всё умрёт*/); 

for ($i = 0, $sz = count($usersWithAv); $i < $sz; $i++) :?>

<?php $current = $usersWithAv[$i]; ?>
<?= $current->first_name?>    
<?php endfor;?>

всё. Где здесь та самая сложность, которую вы пытались воссоздать с помощью ООП? Оно создано для того, чтобы упрощать сложные вещи, а не усложнять простые. Набивайте себе руку чтобы видеть, где какие вещи улучшить, и не улучшайте то, что ещё не выполняет своих задач.

[Алексей]

Decadal, т.е. получается, для всего, что относится к запросу из базы юзеров, мы просто создаем некий один класс по принципу UserQueries, и создаем методы для всех возможных запросов, которые есть или появятся во всем веб приложении? А потом из, например, Posts обращаемся к классу UserQueries и получаем лайкнувших, из новостей опять обращаемся к UserQueries и выбираем метод для получения тех, кто поделился и т.д. В итоге, если что-то поменяется в БД с таблице Users, мы всегда сможем внести изменения в одном файле и не париться о том, что где-то еще есть запросы? Я правильно понял? Для этого и нужно разделять логику и запросы к БД?

Извиняюсь за свою тупость... Но читаю книгу
Все хвалили, купил, а там как бы принципы, методы все вроде понятно объясняют, и я понимаю все по отдельности, но вот как это все соединить и нормально использовать - не получается...

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

В любом случае, спасибо, что потратили на меня время, я все-таки вроде разобрался, буду пробовать это все на практике...

[Decadal]

Евгений, Я надеюсь, что мой ответ "да" не засядет в голове навечно) В данном случае - да, мы делаем источник однородной информации из класса UserQueries.

Однако учтите, что это выход в том случае, если вы не используете фреймворки. В фреймворках предложены свои решения этой проблемы, и вам следует ознакомиться и осознанно принять предлагаемое ими решение (типа Active Record yii, или Doctrine из Symfony) или отвергнуть в пользу своего. Плюс, в каких-то проектах уже исторически сложился другой стиль, или другая архитектура - всё это разнообразное, и по-прежнему ООП (или пытается им быть). Вот где сложность, десяток ответов на вопрос - и все по-своему правильные. Ориентируйтесь на конкретную ситуацию: чем больше ситуаций вы увидите, тем больше разнообразных инструментов получите в распоряжение (вернее, поймете их применение).

А потом из, например, Posts обращаемся к классу UserQueries и получаем лайкнувших, из новостей опять обращаемся к UserQueries и выбираем метод для получения тех, кто поделился и т.д. В итоге, если что-то поменяется в БД с таблице Users, мы всегда сможем внести изменения в одном файле и не париться о том, что где-то еще есть запросы? Я правильно понял? Для этого и нужно разделять логику и запросы к БД?

Направление мыслей верное, идею вы поняли. Правда, насчет Posts и UserQueries нужно еще немного подумать, вдруг найдёте решение получше)

Извиняюсь за свою тупость... Но читаю книгу

это не тупость, а обыкновенная проблема теории в вакууме. Вы читаете эту книгу лишь затем, чтобы через два года страданий и проб наконец понять, к чему именно применять сказанное в ней, и к чему не применять. Вам хочется сделать очень правильное приложение по всем рекомендациям - поэтому каждый свой маленький шажок будете выдавать каскады вопросов, ответы на которые опять вынуждают спрашивать.
Хотя ничего страшного нет в том, чтобы сделать неправильное приложение. Некоторым людям только так и возможно понять, как лучше: сделать что-то плохое и придумать, как можно было бы улучшить это.

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

Вы читаете php, да? Так вот: пока вы работаете с php, будьте спокойны: 90% времени выполнения скрипта всё равно сожрёт база данных. И то что какие-то массивы перебираются по два раза, настолько незначительно, насколько незначительны три звезды в космосе.
Если что-то медленно работает, провисает или тормозит - почти всегда это из-за бд. Чтобы двигаться дальше, пока что просто смиритесь с этим.

Например:
есть функция, которая перебирает строку и выводит каждый символ. И есть функция, которая считает количество символов в строке. Вам приходится использовать их две сразу, и тут же вы замечаете, что можно было бы выполнить их в одном проходе цикла: и считать символы, и выводить их. Заманчиво, но во что превратится код? Мы разделяем: сначала посчитаем количество, потом переберем строку. Зачем? Чтобы сделать код сопровождаемым, и да, в ущерб производительности.
Названия переменных занимают место в оперативной памяти. $userCount занимает в девять раз больше места чем $a. Вы же не будете называть все переменные $a, $b, $c? хотя это и экономия памяти.

[Алексей]

Пока разбирался, набрел на такую вот проблему...
Вы писали, что пост должен знать кто его лайкнул... и поэтому в классе Post создаем метод "getLiked", который получает пользователей, которые его лайкнули.
Но как быть с такой ситуацией...
Нужно с помощью ajax получить лайкнувших пост, комментарий, фото и т.д.
У меня только такие мысли... Нужно создать отдельный класс Liked, куда мы будем передавать тип записи и id записи. Например ('posts', 3554) - этим мы говорим, что нужно получить пользователей, которые лайкнули пост с id == 3554.
И вот тут вопрос возник... В классе Liked мы проверяем что это за тип записи, но дальше не понятно... то ли нужно обращаться к классу Posts, то ли создать класс, который будет получать и обрабатывать лайки от любых записей, будь то posts, comments или photos.
Получается, что нам не нужно создавать метод getLiked() в классе Post, а только обращаться к классу Liked из класса Post

[Decadal]

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

GET /post/<id>/userLikes

PostController {

function actionUserLikes($postId) {
 
// вот способы,которыми можно получить нужные данные:
// Custom (самописные модели)

$model = new UserLikes(); //модель для таблицы UserLikes, отвечает за добавление лайков, удаление лайков и вывод инфы
// 1. Для производительности

// getUsersByLikes содержит сырой запрос вида select name from users ....
// и никак не связан с вашей моделью пользователей, пока не будет усложнения бизнес-логики
 $users = $model->getUsersByLikes($postId);  

// 2. Для масштабирования
//берем сначала айдишники юзеров
 $userIds = $model->getUserIdsByLikes($postId);  
 $userModel = new User(); 
//решаем, что с ними делать - вдруг нам понадобятся не только юзеры, а связанная с ними инфа
 $users = $userModel->findAll($userIds); //или как у вас там выбираются все юзеры
// OR
 $users = $userModel->findAllWithAvatars($userIds); 
//------
// ActiveRecord style
// 1. 
 $postWithLikes = PostRecord::find()->where(['id' => $postId])->with('userLikes')->all(); 
 // 2.
 $postWithLikes = $this->getModel($postId)->userLikes(); 
 // 3. (by foreign table)
 $tmp = UserLikeRecord::find()->where(['post_id'=>$postId])->with('users')->all();  
 $users = (!is_null($tmp)) ? $tmp->users : []; 


   }
}

Answer 2

[Dmitry MiksIr]

То, что вы говорите - называется патерном Identity Map и реализовано в некоторых ORM системах, например, в Doctrine.

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

Получая данные из базы проверять - есть ли в кеше сущность с таким же идентификатором.

> Или все-таки это правильно, создавать новый объект в каждом запросе

Правильно, имхо, что бы был только один объект с одним идентификатором, а если нужно иное поведение - сказать это отдельно.

Answer 3

[DTX]

Добавлю свои пять копеек к ответу Decadal

Советую прочитать доку по ларавелю, или хотя бы lumen (микрофрейморк, брат ларавеля) в частности раздел про Eloquent. Многое должно встать на место.
Т.е. у нас есть модель пользователя:

$user = User::find(1); //пользователь с id = 1
$users = User:all(); //все пользователи

Далее мы можем настроить отношения моделей и, например, сказать, что у пользователя могут быть созданные им посты. Тогда если у нас есть пользователь $user, мы сможем получить все посты, которые он лайкнул, просто написав
$likedPosts = $user->posts
К слову, это тоже самое, что и

$likedPosts = Posts::where('author_id', $user->id)->get()

В итоге всё получается очень красиво. Все поля пользователя, грубо говоря, есть в классе User, а все поля постов пользователя есть в User->posts, которые (посты) являются экземплярами класса Post.

https://laravel.com/docs/5.5/eloquent
https://laravel.com/docs/5.5/eloquent-relationships

Comments

[Decadal]

user->posts это скорее все посты которые юзер создал а не лайкнул, как и следует из вашего замечания Posts::where('author_id', user->id) // так какой же он автор поста, он 'лайкер' поста должен был быть?..

Я очень не хотел говорить о фреймворках потому что на места все не станет а скорее окончательно запутает. Пусть человек кодит себе дальше а не читает документации фреймов, которые не юзает, придет время сам поймет что читать.

[DTX]

Decadal, user->posts это для упрощения. Можно реализовать user->-likedPosts при желании

Я очень не хотел говорить о фреймворках потому что на места все не станет а скорее окончательно запутает

Поэтому я порекомендовал две конкретные главы

[Алексей]

Спасибо за ответ!
А что в итоге получает переменная в этой строке?

$likedPosts = Posts::where('author_id', $user->id)->get()

Уже готовый список объектов User? Т.е. где-то в методе get() есть обращение к классу User?

[DTX]

Евгений, нет, массив объектов постов.
А вот тут массив юзеров:
$users = User::where('id', '>', 10)->get()
Тут where() строит запрос по нужной модели/классу (юзеров или постов), а get() просто его выполняет