Как правильно реализовывать модели в MVC структуре сайта?

Question

[Dreaded]

Я делаю свой первый учебный проект используя шаблон MVC.
Модели я начал создавать руководствуясь правилом - для каждой сущности в БД - своя модель.

Сейчас словил ступор вот в таком моменте: Например, у меня на сайте есть блок вывода сообщения, в котором задействованы три сущности: Само сообщение(основная сущность), Пользователь оставивший сообщение, и Файлы прикрепленные к сообщению. Получается, что для того что бы отобразить одно сообщение - мне нужно объединить данные трёх моделей.

Может быть это неправильный подход, и нужно было просто сделать модель сообщения как сущность сайта(то есть уже хранящая в себе данные трех таблиц)? Или совместить два этих подхода, и отдельно создать модели каждой сущности в бд, + модель сущности сайта?

Comments

[Yan-s]

Получается, что для того что бы отобразить одно сообщение - мне нужно объединить данные трёх моделей.

Разве это проблема?

[Алексей]

Само сообщение(основная сущность), Пользователь оставивший сообщение, и Файлы прикрепленные к сообщению. Получается, что для того что бы отобразить одно сообщение - мне нужно объединить данные трёх моделей.

Собственно, так и оставьте.

Модель сообщения как сущность сайта? Модель пользователя с его данными с точки зрения личного кабинета тоже сущность сайта, нет? Насколько это необходимо? Насколько это сложнее в реализации, чем первый подход?

При отображении сообщения объединять все данные внешних по отношению к сообщению сущностей необходимости же нет. От пользователя - логин/имя + аватарка, от файла - url + иконка. Усложнять вряд ли стоит.

[Kirill Mokevnin]

Воспользуйтесь готовой ORM или хотя бы посмотрите как они устроены. https://laravel.com/docs/5.6/eloquent

Answer 1

[thyratr0n]

Существует множество подходов к решению этой проблемы. Все зависит от того, сколько времени вы готовы потратить на их реализацию, а так же от используемых фреймворков. Если вы говорите про "модель", значит, вы используете паттерны либо ActiveRecord, либо Table.

1. Если вы используете готовые фреймворки, то юзайте инструментарий "из коробки" - для учебного проекта этого будет достаточно.
2. Если вы сами пишете, то тут возможны варианты:
2.1 Можно создавать классы-компоненты (storage), которые будет организовывать выборку и нужным образом компоновать классы между собой:
2.2 Можно создать в БД вьюхи (view), которые объединят нужные данные, а в коде использовать, как единую сущность.
2.3 Можно написать постобработку для CRUD-операций (триггеры в БД, events в коде и тд), которая будет собирать все данные в четвертую таблицу, отдельную. Тогда просто один класс доступа будет.

Варианты во 2-м пункте расположены по возрастанию уровня сложности.

Если вы сами пишете, то в том, что касается кода, я советую на выходе собирать единый объект (не используйте для композитного объекта понятие сущности - это не корректно). Как вы его будете собирать - зависит от того, что вы выберете из пунктов выше. Но в любом случае итоговый композит должен выглядить подобно:

class Comment
{
    /**
     * Я бы еще рекомендовал передавать связанные сущности в конструктор, ибо без них комментарий не имеет смысла
     * @param User
     * @param File | null
     **/
    public function __construct(User $user, File $file = null); //я б
  
    /**
     * тут никаких интерфейсов, ибо интерфейсы, дублирующие сущность - моветон
     * @return User
     **/
    public function getUser(): User 
    
    /**
     * @return File
     **/
    public function getFile(): File
}

Либо использовать фабрики. Но фабрики - это уже "на вкус и цвет", как говорится.

Answer 2

[Дмитрий]

У вас должно быть три сущности:

interface MessageInterface
{
    public function setUser(UserInterface $user);

    public function attachFile(FileInterface $file);
}

interface UserInterface
{
.....
}

interface FileInterface
{
.....
}

И должна быть фабрика, которая умеет все это дело собрать вместе, используя MessageInterface::setUser и attachFile. В любом случае модели должны быть отдельно, а данные должны загружаться через сеттеры.

Можно сделать три фабрики и сделать немного по другому:

interface FileFactory
{
    public function getFiles(MessageInterface $message)
}

Хотя такой вариант я не очень люблю. Вариант с сеттерами намного лучше.

Comments

[ozornick]

...и работать будет так?

class Message_Controller {
    public function showMessage() {
        $post = Db::find(1);
        $user = Db::find($post->user_id);
        $file   = Db::find($post->file_id);
        
        $message = MessageFactory::create($post);
        $message->setUser($user);
        $message->attachFile($file);

        $view->render('template', ['message' => $message]);
    }
}

[Дмитрий]

Нет, зачем вы билдинг $message делаете в контроллере?

У вас должен быть репозиторий (Db) для получения данных, который в свою очередь данные из хранилища преобразует в объект с помощью фабрики.

Т.е. MessageFactory должен знать, какие $user и $file относятся к этому сообщению.

По нормальному ваш код должен выглядеть вот так:

$message = $messageRepository->findOne(1);
// в $message уже есть пользователи и файлы.

а в findOne через фабрику уже заполняется setUser, attachFile и так далее.
Создание экземпляра класса Message и заполнение связанными данными должно быть в одном месте.

[ozornick]

Дмитрий Богданов, я так и подумал, но решил узнать подробности. Теперь надо подниматься на ступень выше, к репозиториям.

class Message_Controller
{
    /**
     * Как здесь оперировать передачей?
     * Если может понадобится более одного репозитория?
     * Использовать статичную фабрику?
     *
     * Или передать выполнение сервису? Тогда как его загружать?
     * Где пробросить коннект или конфигурацию?
     */
    public function __construct()
    {
        //$this->repository = RepositoryFactory::create('Message');
        $this->repository = MessageRepository::create($connect);
        $this->service = ServiceProvider::create('Message');
    }

    public function showMessage()
    {
        $message = $this->repository->findOne(1);
        $message2 = $this->service->findOne(1);
        $message3 = $this->service->repository->findOne(1);
    }
}