Как Вы думаете стоит ли дробить модели (PHP / Laravel)?

Question

[kor-elf]

Здравствуйте! Я обычно не задаю вопросы и пытаюсь самим разобраться. Но тут интересно мнение людей. Сегодня я задумался разделять модели на 4 части (PostCreatedModel, PostUpdatedModel, PostDeletedModel, PostFindModel). Мне кажется, что в будущем так будет легче расширять код. Или лучше не дробить модель на части? Кто что думает об этом? :)

Comments

[JhaoDa]

Нам самим догадаться какой смысл ты заложил в это решение или расскажешь?

[kor-elf]

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

[65536]

kor-elf, да выглядит это всё тяжело, видел в чужих проектах модели на полторы тыщи строк. Это уже не модели, а непойми что. Я вообще в моделях по минимуму пишу, исключительно как адаптер к таблицам использую. Логике в них не место. логика может охватывать не только одну модель, а несколько. И в какой из них тогда метод писать? Бизнес-логику лучше хранить отдельно и абстрактно, то есть она не должна завязываться на какие-то технические детали системы, на какой-то там адаптер к бд. Модель это объект, который можно передавать как аргумент и там что-то с ним делать. Иногда даже связи можно на ходу описывать (не описывая в самой модели). Вот пример:

public function getWarehouseAreas(\ss\multisource\models\Warehouse $warehouse)
    {
        if (!isset($this->warehousesAreas[$warehouse->id])) {
            $this->warehousesAreas[$warehouse->id] = $warehouse->hasMany(\tdui\company\models\Area::class)->get();
        }

        return $this->warehousesAreas[$warehouse->id];
    }

Сама модель Warehouse знать не знает о том что на нее указывают модели Area (или еще какие-нибудь). Да и не только связей касается а всего. Со временем пиления проекта действий над моделями становится настолько много что описание их в классе модели вообще худшим местом становится. Разбиение по типам действий сделает 4 файла покороче вмето одного длинного но проблему нелогичного размещения кода только усугубит

[kor-elf]

65536, Спасибо за хороший пример. С Вами полностью согласен.

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

65536,

исключительно как адаптер к таблицам использую

это в корне не верно
Модель - это НЕ адаптер к БД

логика может охватывать не только одну модель, а несколько. И в какой из них тогда метод писать?

в модели, которая инициирует все процессы

Бизнес-логику лучше хранить отдельно

бизнес-логика, относящаяся, например, к модели Пользователь, должна храниться в модели пользователя. Иначе в таких моделях нет никакого смысла

[65536]

Северное Сияние, неважно как это называется. Я о том что с моделью может происходить куча разных действий, в том числе одноименных, но в разных контекстах. Как в таком случае в одном файле это описывать, префиксы к методам городить что-ли? Единственный плюс прописи всего в модели это то что прям на ней их можно будет вызывать. А когда этих методов станет 100, как их в этом файле разложить по "категориям"? Как вариант наэкстендить тематические классы, но извне работать с ними удобнее (мне). Потому что можно построить дерево из классов похожее на логическую структуру делаемой программы и в ней в правильных местах совершать манипуляции над моделями, модифицировать, связывать, да хоть по кругу пускать. А прописывание всего в классах моделей завязывает архитектуру на плоский список таблиц в бд. Имхо короче. Это не тема для спора, я просто свой жизнеспособный вариант спасения описал

[jazzus]

65536, что вы там мутите или курите я хз. В Ларавел куча своих методов в моделях и куча примеров как их использовать. Не нужно выдумывать ни абстракции, ни PostCreated ни еще что-то. За вас все уже придумали.

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

jazzus, верно, тут пол топика наркоманов

Answer 1

[netrox]

Почитайте про CQRS и DDD .

Comments

[kor-elf]

Спасибо.

[kafkiansky]

> Как мне написать правильное подключение к базе данных?

Почитайте про ООП.

> Как в MVC правильно работать с моделями?

Почитайте про Event Sourcing.

> Как Вы думаете стоит ли дробить модели?

Почитайте про CQRS и DDD.

Интересно, а когда умные слова закончатся, какие пойдут советы. При чем тут DDD и CQRS - неясно вообще.

Answer 2

[Дмитрий Б]

Создай одну модель. Создай к ней отдельный класс-сервис, который будет управлять моделью.
В сервисе опиши набор методов: create, update, delete, deactivate и прочее.
Если метод простой, оставляешь реализацию в этом классе.
Если метод сложный, например export, можно вынести в отдельный класс, и вызывать его в методе сервиса.
Пример.

$users->update($model);
$users->deactivate($model);
$users->export(); // Внутри вызываешь new UsersExport()->export();, что б не засорять сервис

Если какой-то набор методов легко выделить в одну группу, лучше создать новый сервис.
Например не пихать аутентификацию в Users сервис, а создать сервис UsersAuthenticate.

$usersAuthenticate->register();
$usersAuthenticate->authorize();

Comments

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

$users->update($model);

позвольте узнать, зачем это масло маслянное в виде абсолютно лишней прослойки, которая будет плодить копипаст однотипного кода?

Чем не устраивает

$user = User::updateOrCreate(
    ['email' =>  request('email')],
    ['name' => request('name')]
);

[Дмитрий Б]

Код вырастит, логика увеличится и узнаете

[kor-elf]

Спасибо за пример. Да, такой вариант мне нравится. Буду пробовать.

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

Дмитрий Байбухтин, это не ответ, мой друг.

Давай реальный пример.

[Дмитрий Б]

Северное Сияние, я тебе не друг. Примера не будет

[jazzus]

Дмитрий Байбухтин, в сервисы имеет смысл выносить какие-либо процессы, а не повторять методы Ларавел. Код $users->update($model) говорит только о том, что здесь выдуман очередной велосипед в который нужно лезть, чтобы понять что это и зачем

[Дмитрий Б]

jazzus, суть данного процесса в том, что бы использовать модели лишь как способ доступа к БД, с возможностью валидации данных.
Если пихать логику для работы с моделью в саму модель, как это например предлагает Yii, получается гребаный монстр, который содержит в себе все, что только может быть.
Мое предложение позволяет вынести работу над моделью в отдельные классы. Которые могут работать как с определенной моделью, с несколькими моделями или же вообще без них.
Подобное разделение отлично показалось себя на проектах среднего уровня сложности, потому как каждый класс имеет определенное назначение и отлично его выполняет, а не копит в себе все, что может.
Классы простые и читабельные. Что бы понять как работает какая-то сложная логика, достаточно посмотреть ответственные за это классы, а не перекапывать тонны раскиданного по проекту удобрения.
Конечно же есть и другие варианты решения данной проблемы.

[jazzus]

Дмитрий Байбухтин, $users->update($model) это не читабельный класс. Это ненужная путаница. Читабельный $user->update($data) который Ларавел уже придумал. Выносить в сервисы - да, но не дублировать методы Laravel.

[Дмитрий Б]

jazzus, прекрасно, пользуйтесь

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

Дмитрий Байбухтин,

использовать модели лишь как способ доступа к БД

марш читать про МВС

Модель НИКАКОГО отношения к БД не имеет, не имела и не будет иметь никогда.
Модель может быть в программном коде, который вообще не использует БД.
Модель - это совокупность бизнес-данных и бизнес-логики.

Если фреймворк НЕЯВНО сделал реализацию Модель+AR, это не значит, что Модель - " лишь способ доступа к БД"

[Дмитрий Б]

Северное Сияние, это не имеет значения в данном случае, хватит слюнями захлебываться

[65536]

Северное Сияние, jazzus, вы там гостевую книгу пишете что ли?

[jazzus]

65536, в твоих проектах мирового масштаба тоже можно не говнокодить

Answer 3

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

Сегодня я задумался разделять модели на 4 части (PostCreatedModel, PostUpdatedModel, PostDeletedModel, PostFindModel). Мне кажется, что в будущем так будет легче расширять код. Или лучше не дробить модель на части? Кто что думает об этом? :)

это бред, возникший в пьяном угаре.
Полное непонимание МВС.
Модель - одна. Всегда. Это класс, отожествляемый с предметом реального мира (Товар, Сервер, Строение) или абстрактной сущностью, необходимой для решения задачи (Заказ, Доступ, Роль и тд).

Операции с моделью выполняет другой слой. В классических фреймворках - это реализация паттерна ActiveRecord, внедренная разработчиками фреймворка в саму модель, ЧТО СОЗДАЕТ ИЛЛЮЗИЮ, ЧТО МОДЕЛЬ - ЭТО ВСЕГО НАВСЕГО ДРАЙВЕР К БД. Это в корне не верно. Есть другие схемы, например Data Mapper, когда модель не умеет сама себя CRUD-ить, а передается в качестве "аргумента" в независимую от неё структуру классов. Но сути это не меняет:

Никаких PostUpdatedModel быть не должно, модель ВСЕГДА одна.
Как она заносится в БД, обрабатывается и КТО выполняет эти операции - диктует, как правило, архитектура конкретного фреймворка. Надо просто смотреть документацию и примеры.

Comments

[kor-elf]

Спасибо за разъяснения. Просто когда модель разрастается на большое кол-во методов, потом сложновато его поддерживать. Вот и задумался, как можно эту проблему решить. Из всех ответов, я понял что нужно решать проблему по другому.

[kafkiansky]

Полное непонимание МВС. Модель - одна. Всегда. Это класс, отожествляемый с предметом реального мира

И не стыдно писать такое? Покажи мне пальцем, где ты прочитал, что модель должна быть ВСЕГДА одна. Для моделирования предметов реального мира попросту не хватит одной модели, если речь, конечно, не про карандаш или глобус.

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

kafkiansky,

И не стыдно писать такое?

давай ты. перед тем как писать комментарий, сначала протрезвеешь?

Для моделирования предметов реального мира попросту не хватит одной модели

рукалицо... что ты хотел этим сказать?

[kafkiansky]

Северное Сияние, смоделируй мне автомобиль одной моделью или хотя бы двигатель.

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

kafkiansky, кто сказал что модель будет одна?
Модели будет столько, сколько нужно.
Я писал о наличии одной модели в КОНТЕКСТЕ того, что написал автор.

Естественно будет модель Двигатель, Стартер, Генератор, Помпа и тд