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

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>

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