Yii. Как вы проектируете свои модели?

Question

[Zohei]

Добрый день.
Как вы проектируете свои модели для бэкенд, фронтенд и других, например, апи модулей?
Опишу свои затруднения на примере модели ТОВАР.
С одной стороны, есть большое кол-во общих методов для классов Product во всех модулях, например:

public function getPrice() {
    return format($this->price);
}

Логичным кажется вынос общих методов в CommonProduct и далее все товарам наследоваться от него.. SiteProduct, AdminProduct, ApiProduct...

С другой стороны, хочется, использовать свой класс ActiveRecord в каждом модуле (AdminActiveRecord, ProductActiveRecord, ApiActiveRecord..)
Например, один раз для фронтенда в SiteActiveRecord прописать defaultScopes для вывода только опубликованных данных и радоваться что условие подтянулось ко всем запросам в десятке классов.

public function defaultScope()
    {
        return [
            'condition'=>'active=1, 
        ];
    }

Хочу разобраться какой подход наиболее верный

PS. Всем кто откликнулся на проблему плюс в карму) отметил ваши сообщения решением

Answer 1

[Сергей Протько]

Откройте для себя путь DDD. Доменная модель на все приложение одна и не привязана к модулям фреймворкам и вообще. Правда в контексте Yii сделать чистые модели не получится, php все же не ruby.

Comments

[Zohei]

В контексте php (в идеале, yii), ссылок на пример удачной реализации под рукой не найдется?)

[Сергей Протько]

@Zohei под yii в открытом доступе вообще не видел ничего достойного, как это не странно. Да и вообще тяжко так сходу сказать.

[Сергей Протько]

@Zohei https://github.com/leopro/trip-planner - вот вроде более мение вменяемый пример, но в контексте Symfony.

[Zohei]

@Fesor Спасибо, посмотрю, примеру с ActiveRecord, конечно, цены бы не было)

[Сергей Протько]

@Zohei в том то и проблема что active record это слой работы с базой данных. Вообще можно и на AR делать все, просто тогда модель будет анемичной.

вообще в сети массы разговоров на этот счет. Если бы кто написал какую статью в контексте PHP именно было бы найс. Есть примеры под RoR - можно там чего интересного подчерпнуть.

samolisov.blogspot.com/2012/10/anemic-domain-model.html

Answer 2

[Filipp Shcherbanich]

В модулях модели можно наследовать все основные модели, и прописывать в дочерних что-то вроде

public function defaultScope()
    {
        return [
            'condition'=>'active=1, 
        ];
    }

Comments

[Zohei]

Можно. Но душит лень, когда один и тот же код требуется прописать десятку моделей)

[Filipp Shcherbanich]

@Zohei, ну раз лень, можно в основной модели и прописать, от этого плохо никому не станет)

[Zohei]

@scherbanich а пример рабочий есть?) Как например прописать в defaultScopes правило, чтобы в админке выводились все записи, при этом на сайте показывались только опубликованные.
Или например в beforeSave прокинуть разом для всех моделей админки сохранение истории правок, а для сайта кол-во просмотров)
У меня нет решения как совместить оба похода, потому и спрашиваю. Может второй подход вообще не верен с точки зрения проектирования и я зря заморачиваюсь....

[Filipp Shcherbanich]

@Zohei, у модуля создаете модель, наследуемую от общей модели ( например Product), а дальше прописываете в ней правила по документации www.yiiframework.com/doc/guide/1.1/ru/database.ar#... . Ну и после всего этого можно использовать данную модель в контроллере модуля :)
Надеюсь понятно написал)

[Zohei]

ммм.... нет) немного не то. Это то же нужно во все модели модуля прописать один и тот же метод. Вопрос в том как это сделать в одном месте сразу для всех моделей модуля...))
У меня была безумная мысль унаследовать AdminActiveRecord от CActiveRecord и прописать в нем defaultScopes... тогда все модели админки унаследованные от него подхватят нужный код... А общие модели типа CommonProduct сделать статическими хелперами. Но как-то неправильно это.

[Filipp Shcherbanich]

@Zohei, лучше это прописать как раз в каждую модель модуля, ибо потом появятся какие-то различия и всеравно придется выносить, а так все будет максимально просто

Answer 3

[_ _]

Почему у вас для бэкенда, фронтенда и апи разные модели?

Comments

[Filipp Shcherbanich]

у него разные модули, и в каждом можно расширить общую модель

[Zohei]

Огромное кол-во правил валидации у бэкенд и фронтенд моделей.
В админке, например, при создании товара Супер Админу выводится на выбор список городов и магазинов; Админу Города id города проставляется автоматически, показывается только список заведений; Менеджеру заведения уже id заведения должен проставиться автоматом и тд...
Тоже самое касается связей (relations), методов поиска записей (типа search) и прочего прочего прочего...
У других модулей другая логика, права и тд.
Если все это пихать в одну модель, то боюсь код быстро станет не поддерживаемым даже самим разработчиком

[Сергей Протько]

@Zohei валидацию можно группами разруливать. Правда если в Yii все еще нельзя несколько групп валидации применять то да, печаль.

[Zohei]

в yii есть сценарии, если вы о них...
Вывод полей формы в зависимости от прав разруливается автоматом при помощи сценариев и CFrom, довольно удобно.
В yii2 не знаю как, не смотрел даже, но вроде как валидация там другим путем пошла...

Answer 4

[old-calm]

В разделе common удобно определить общие методы работы с сущностью. А конкретизацию сущности прменительно к задачам и бизнес логику разнести по местам назначегия: бекэнду, фронтенду, апи. Важнее разнести модели и бизнес логику, чем модели в разделах, имхо.