Когда объект должен быть включен в качестве члена другого объекта, и когда он всегда должен быть автономным?

Question

Пример проблемы:

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

Из того, что я вижу, есть три различных способа извлечения данных этого вида из модели:

1. Объект Post может включать полный объект User в качестве члена. Представление тогда получило бы доступ к пользователю как это: $post->user->getReputation(). Это кажется более понятным, так как Контроллер может просто запросить сообщения и покончить с этим, но все же неэффективно, поскольку Посту, вероятно, не всегда нужен 1010 * полноценный Пользователь. Я предполагаю, что это работает достаточно хорошо, если объект User является относительно легким, что, вероятно, было бы. Тогда проблема может заключаться в том, что вам нужно будет продублировать код поиска пользователя как часть запроса пост-поиска.

2. Объект Post может содержать только идентификатор пользователя. Когда сообщение или сообщения возвращаются в контроллер, контроллер может затем извлечь уникальные идентификаторы пользователя из возвращенного набора и передать их фабрике пользователей. Возвращенные объекты User будут затем передаваться вместе с исходными сообщениями, установленными для View, как отдельная коллекция. Затем представление может получить информацию о пользователе, используя что-то вроде $users[$post->getUserId()]->getReputation().

3. Гибридный подход: включите объект User в объект Post, но используйте извлечение уникального идентификатора и извлечение пользователя как часть метода извлечения Post. т. е. Post::getPosts() будет захватывать все соответствующие сообщения и преобразовывать их в объекты с нулевыми членами пользователя, затем извлекать все идентификаторы пользователей и передавать их в User::getUsers(), а затем назначать пользователей соответствующим сообщениям перед возвратом набора сообщений в звонящий.

Я предполагаю, что я имею в виду, как мне узнать, когда объект должен содержать в себе другой объект? Нечисто ли / пахнет кодом, чтобы вместо этого возвращать такие связанные объекты отдельно, при этом ни один объект не знает, что другой был найден. Я склоняюсь к отдельной концепции поиска - она ​​кажется наиболее эффективной - но на самом деле кажется, что они слишком связаны, чтобы это имело смысл.

Answer 1

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

Edit: Я попытаюсь объяснить это на примере.

Скажем, у вас есть представление, в котором вам не нужна информация пользователя, затем вы можете настроить / настроить вашу почтовую фабрику для использования ленивого прокси ( см. Википедию ) для пользователя, который будет содержать только Я БЫ. Таким образом, доступ к пользователям не требуется.

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

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

Answer 2

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

Answer 3

Мне кажется, что это еще один случай внедрения зависимости.Достаточно общая идея, которая может вам помочь.

WIKI ЗАВИСИМОСТИ ОТ ЗАВИСИМОСТИ

Прочтите также кое-что об инверсии контроля.