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

Question

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

Всем привет!
Появилась у меня в голове такая путаница. Есть несколько страниц, на которых выводятся посты. У постов соответственно, есть автор, заголовок и текст + сопутствующие данные вроде даты, кол-ва просмотров и т.д.
Получается что для того чтобы правильно выводить пост на всем сайте, нам нужна одна точка получения данных. Скажем класс PostsModel это и есть тот класс. Он работает с базой данных и делает все, что связано с постами. И тут как раз проблема.
Нам нужно передать в класс PostsView, который отвечает за вывод поста в виде HTML, не только данные поста, но и данные об авторе. А значит объект User так же должен получаться в одной точке, например UsersModel.
Ведь мы не можем просто взять и в PostsModel выполнить JOIN необходимых полей из таблицы Users? Это ведь нарушает правила единой ответственности? т.е. пост не должен знать ничего о полях пользователя.
Значит есть вариант получить данные постов, создать из них объекты, положить в коллекцию постов, а в коллекции создать метод, который сможет добавить объект User к нужному посту коллекции. Надеюсь я верно рассуждаю.
После запрашиваем в модели UsersModel всех пользователей, которые были авторами выбранных постов и кладем к каждому посту если есть совпадения.
Но в таком случае, получается, что вид поста будет общаться с методами пользователя.
Пожалуйста, направьте на путь истинный, совсем запутался.
Что почитать по этой теме, может какие-то паттерны или где подсмотреть...

Comments

[dmitriy]

Ведь мы не можем просто взять и в PostsModel выполнить JOIN необходимых полей из таблицы Users? Это ведь нарушает правила единой ответственности?

то что PostsModel ходит в БД это уже нарушение этого принципа

Answer 1

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

Немножко не ответ

Для класса PostsModel:
Автор Поста является потомком Поста.
Пост для автора - Родитель.
Пост для даты поста - Родитель.

*Тут была реплика про уровень комьюнити тостера, и даже "Кураторов Тега", которые позволяют себе нести вышепроцитированную чушь, но я решил её опустить, т.к. разумный человек и так поймёт со временем*

Совет - развивайте критическое мышление и фильтруйте информацию, не верьте всему в интернете, даже если у этого 100500 плюсов на каком-нибудь ресурсе типа Хабра/SO/Medium/Тостер и т.п.

Алексей Коновалов,

нам нужна одна точка получения данных.

Нам не нужна "единая точка получения данных". У вас есть ваши модели(сущности, доменные модели) - это компонент вашей системы отвечающий за часть бизнес-логики.
Так же у вас есть представления данных. Представлений данных может быть множество. Не нужно реиспользовать одну и ту же модельку для логики/записи и для чтения(представления, UI).
Выбрали данные из БД(raw SQL/Eloquent/DQL смапленный на DTO, что угодно)
->заполнили ими структуру которая сформирована исходя из нужд клиентского модуля(Frontend`а вашего),
-> привели к нужному формату(json etc.) и отдали на фронтенд

Он работает с базой данных и делает все, что связано с постами. И тут как раз проблема.

Очень хорошо что вы подметили что это проблема, серьёзно. Именно по этому "Active Record" - антипаттерн.
Некоторые, к большому сожалению, годами к этому не могут придти, того больше - отстаивают каждое архитектурное решение какого-нибудь Laravel не с позиции инженера, а с позиции религиозного фанатика.

Модели для записи ничего про HTTP, Request и представления знать не должны. Модели на чтение по сути просто структуры данных.

Answer 2

[xmoonlight]

Для класса PostsModel:
Автор Поста является потомком Поста.
Пост для автора - Родитель.
Пост для даты поста - Родитель.
и т.д.

Comments

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

Так я правильно делаю?

[xmoonlight]

Алексей Коновалов,

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

Это не нужно. Т.к. класс PostsModel должен заполнить все поля поста при создании объекта класса. А эти поля - связаны в базе (если всё корректно сделано...). Т.е. он своими методами забирает ТОЛЬКО НУЖНЫЕ ДАННЫЕ! для класса PostModel (т.к. другие - ему не нужны: логин, пароль, дата входа и прочее).
А так - всё верно.

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

xmoonlight, Значит получать данные из таблицы Users нужно из модели PostsModel?
Мы же нарушаем все правила...
Например, мне нужно вывести аватар пользователя. Значит в модели PostsModel джойнить еще и таблицу с аватарами? Более того. Получив имя изображения на сервере. Мне нужно еще сгенерировать ссылку на него. Если я буду её прописывать везде где использую аватар пользователя. То я опять нарушаю правило, что код не должен дублироваться иначе при изменении я где-то забаду поменять ссылку и будут ошибки.
В моем случае я бы просто вызывал метод getPhotoUrl у объекта User. И где бы я его не вызвал - мне достаточно поменять ссылку только в одном месте - в этом методе.

[xmoonlight]

Алексей Коновалов, СТОП! я не говорил как именно их получать! Я лишь, сказал: ОТКУДА их получать! Это разные вещи! ))
Получать - ДА: используя методы подключаемых классов для нужных объектов.
Всё верно!

[Антон Р.]

Автор Поста является потомком Поста

Чего???... Мне просто интересно исходя из какой логики вы так придумали? Как сущность Юзер у вас стала потомком сущности Пост?

[xmoonlight]

Антон Р., паттерн проектирования меняется в зависимости от логики обработки конкретного бизнес-процесса (workflow).
Когда будет создание поста - там наоборот будет.
(главное не путать с сущностями и связями в БД!)

[xmoonlight]

Григорий Васильков, Это верный подход! Зависит от workflow (как я уже выше написал...).

Answer 3

[Антон Р.]

Внутри объекта Пост можно создать новый объект Юзер, передать в него id юзера (id юзера ведь у тебя указан для каждого поста, то есть кто автор) и потом уже выводить имя юзера и всё остальное. Короче "композиция": ассоциация, при которой используемый объект создается внутри класса.
В результате у тебя будет одна коллекция постов и всё будет в ней, а не две "кучки" - Посты и Юзеры.

Comments

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

Внутри объекта Пост можно создать новый объект Юзер, передать в него id юзера (id юзера ведь у тебя указан для каждого поста, то есть кто автор) и потом уже выводить имя юзера и всё остальное. Короче "композиция": ассоциация, при которой используемый объект создается внутри класса.

верно
но проблема в том, что это все должно создаваться АВТОМАТИЧЕСКИ
писать на каждый класс метод получения сопряженных записей - это ООП ради ООП, как секс в пр-ве.

[Антон Р.]

Северное Сияние,

верно

- я всё же почитываю нужные книжки.
не совсем понял в плане "автоматически".

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

Антон Р., ну я так понимаю, что в современных ОРМ это все реализовано.
Ты описываешь модели, когда тебе надо получить данные из другой таблицы по внешнему ключу - автоматом срабатывают определенные механизмы и ты можешь сделать
$post->getAuthor()->getName()
где getAuthor() ТЕБЕ не надо описывать. Или, по меньшей мере, его логику.

Answer 4

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

PostsView, который отвечает за вывод поста в виде HTML

никакого PostsView быть не должно - достаточного одного View - это, по сути, шаблонизатор, с буферизацией вывода. Что, по твоему, должен делать PostsView?

Что почитать по этой теме

"Архитектуру корпоративных приложений" Фаулера. Главу "источники данных".

Ведь мы не можем просто взять и в PostsModel выполнить JOIN необходимых полей из таблицы Users?

Я в своем самописном фреймворке так и сделал. Есть метод для JOIN в моей ORM, он возвращает многомерный массив объектов, где каждый конечный элемент (на твоем примере) будет объект модели Поста и Пользователя. Почему так? Потому, что сделать так:

<html>
  Текст поста: <?=$post->getText()?><br>
  Автор поста:  <?=$post->getAuthor()->getName()?> <!-- это самое сложное -->
</html>

- сделать своими силами - очень, очень нетривиальная задача.