2009-10-12 6 views
3

Я просто искал немного советов, в настоящее время мой дизайн БД состоит в том, что у одного пользователя есть много сообщений в блогах. Теперь у меня есть класс пользователя и класс блога.Вопрос PHP OOP

Однако я не уверен относительно правильного способа получить все сообщения блога для этого пользователя. Я создаю функцию getAllBlogs() в пользовательском классе, которая возвращает объекты блога, или я создаю основной класс блога, который вы можете искать пользователем, так что это будет getAllBlogsForUser ($ id)

Спасибо :-)

ответ

6

Я лично использовал бы более поздний вариант. Это связано с тем, что класс блога знает, как бороться с таблицей (-ами) блога. Я бы не хотел писать код DB для конкретного блога в пользовательском классе. С другой стороны, вы все равно можете добавить User::getAllBlogs() в качестве обертки вокруг Blog::getAllBlogsForUser().

+0

Точно. Статический метод в блоге, который может быть вызван методом экземпляра в User, вероятно, является способом выхода. Добавление метода пользователю дает вам удобство и кеширование (см. Мой ответ ниже) – timdev

2

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

Рассмотрим, насколько хорошо они могут играть вместе:

<?PHP 
class User { 
    protected $_blogs; 

    public function getBlogs($force=false){ 
     if (empty($this->_blogs) || $force){ 
      $this->_blogs = BlogClass::getBlogsByUser($this->user_id); 
     } 
     return $this->_blogs; 
    } 
} 

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

+0

+1 дополнительные усилия для реализации кэширования – Tres

0

Я бы использовал оба варианта, как User::getPosts и Posts::findByUserId («Сообщения» как название модели звучат лучше для меня, чем «Блоги»). Оба метода имеют схожие функциональные возможности и которые можно использовать в зависимости от контекста, например, frontend скорее использует модель пользователей, тогда как в интерфейсе администратора методы «finder» могут быть более уместными.

0

Я бы создал оба. Ваш пользователь :: getBlogs() может использовать Blogs :: getBlogsByUserId ($ idUser), поскольку, когда вы находитесь в пользовательском контексте, у вас будет доступ к идентификатору пользователя, чтобы перейти к методу Blogs.

1

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