Разделение приложения на слои

[zelenin]

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

ну вот например ты пишешь какой-то фильтр (в кач-ве стороннего расширения), который вытаскивает определенную запись твоей модели из БД с помощью репозитория. В своем фильтре ты в качестве зависимости указываешь FilterRepositoryInterface, в котором должен быть метод getById($id). Ты же не будешь сам репозиторий реализовывать, поскольку не знаешь какие модели будут у пользователя твоего расширения. Поэтому ты заставляешь пользователя реализовать твой интерфейс и зарегистрировать его через di - перекладываешь (инвертируешь) контроль за реализацией интерйфейса на пользователя.

[nepster]

Если у нас 100% будет только одна реализация, особо не за чем. Если вероятна ситуация, когда потребуется заменить компонент на другой с таким же интерфейсом — есть смысл.

Главный минус абстракции не в производительности (хоть и не без этого), а в том, что код становится более «расплывчатым». Понимать и отлаживать его несколько сложнее.

Если для себя не нашли смысла применить DI, значит в вашем случае его и нет. Но попробовать стоит. Хотя-бы ради того, чтобы когда понадобится, вы знали, как это делается.

DI Удобно применять в каких-то отдельных библиотеках.

А зачем так сильно усложнять, если например можно сделать:

потому что di употребляется в паре с IoC (inversion of controle/инверсия контроля) , т.е. разработчик контроллера не должен ограничивать разработчика приложения в реализации репозитория. Он пишет интерфейс, прописывает его в качестве зависимости в конструкторе контроллера, а разработчик приложения в di прописывает в качестве реализации интерфейса свою реализацию репозитория, которая собственно с помощью di и попадет в конструктор. Например может быть две реализациии: для AR и для DAO, но контроллеру это не важно - ему нужен метод getById().

Ну опять таки вопрос. На простых примерах будет работать. А что если нужно будет 2 репозитория для двух сущностей (вторую сущность нужно ввести исходя из специфической задачи), а автор предусмотрел только один ?

Честно говоря я не видел еще не одного расширения для Yii2, которое бы использовало DI в контроллерах. Обычно сделано топорно и рассчитывается на стандартные задачи. Я когда писал свой такой модуль, предоставил установщик (который копирует демо реализацию в проект, в ней собственно основную роль играют контроллеры), ну и только так можно получить 100% универсальности.

[nepster]

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

ну вот например ты пишешь какой-то фильтр (в кач-ве стороннего расширения), который вытаскивает определенную запись твоей модели из БД с помощью репозитория. В своем фильтре ты в качестве зависимости указываешь FilterRepositoryInterface, в котором должен быть метод getById($id). Ты же не будешь сам репозиторий реализовывать, поскольку не знаешь какие модели будут у пользователя твоего расширения. Поэтому ты заставляешь пользователя реализовать твой интерфейс и зарегистрировать его через di - перекладываешь (инвертируешь) контроль за реализацией интерйфейса на пользователя.

Было бы здорово посмотреть хоть на 1 такое расширение для yii2

[zelenin]

Ну опять таки вопрос. На простых примерах будет работать. А что если нужно будет 2 репозитория для двух сущностей (вторую сущность нужно ввести исходя из специфической задачи), а автор предусмотрел только один ?

что значит две или один? это разные задачи по разному реализумые.

Честно говоря я не видел еще не одного расширения для Yii2, которое бы использовало DI в контроллерах.

потому что yii для кого? правильно, для нубов. Да и контроллеры здесь не причем. Речь про любой объект, создаваемый через Yii::createObject (или как там оно называется).

[zelenin]

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

ну вот например ты пишешь какой-то фильтр (в кач-ве стороннего расширения), который вытаскивает определенную запись твоей модели из БД с помощью репозитория. В своем фильтре ты в качестве зависимости указываешь FilterRepositoryInterface, в котором должен быть метод getById($id). Ты же не будешь сам репозиторий реализовывать, поскольку не знаешь какие модели будут у пользователя твоего расширения. Поэтому ты заставляешь пользователя реализовать твой интерфейс и зарегистрировать его через di - перекладываешь (инвертируешь) контроль за реализацией интерйфейса на пользователя.

Было бы здорово посмотреть хоть на 1 такое расширение для yii2

я писал: когда тебе интересен yii, ты не знаешь как применить di, а когда знаешь как его применить, yii перестает быть интересен) имхо, не повод для споров.

[zelenin]

https://github.com/yiisoft/yii2/blob/ma ... er.php#L46 тут в принципе все очень хорошо расписано
UserLister - это часть расширения например, UserFinder - это твоя конкретная реализация в проекте. В итоге разработчику UserLister не нужно париться с реализацией UserFinder, учитывая некую специфичность конечного проекта (AR, DAO, Mongo, REST) - он просто предлагает разработчику проекта самостоятельно имплементировать необходимый интерфейс.
Пример, где я бы это использовал например: расширение rss. Делаю экшн, в который с помощью di подается RssDataProviderInterface, в котором метод setData()

Код: Выделить всё

interface RssDataProviderInterface
{
/**
* @var RssModelInterface[] $models
*/
public function setData(array $models);

/**
* @return RssModelInterface[]
*/
public function getData();
}

Код: Выделить всё

interface RssModelInterface
{
/**
* @return RssItem
*/
public function getRssItemData();
}

Код: Выделить всё

class RssItem
{
public $title;
public $content;
}
 

Код: Выделить всё

class Post extends ActiveRecord implements RssModelInterface
{
public function getRssItemData()
{
$data = new RssItem;
$data->title = $this->name . ' (из rss)';
$data->content = strip_tags($this->content);
return $data;
}
}
 

Код: Выделить всё

class RssAction extends Action
{

public function __construct(.... , RssDataProviderInterface $provider) {
$this->provider = $provider;
}

public function run()
{
foreach($this->provider as $model) {
$data = $model->getRssItemData();
...
}
}
}

Код: Выделить всё

public function actions()
{
\Yii::$container->set('RssDataProviderInterface', ['class' => 'PostRssDataProvider']);

return [
'feed' => [
'class' => 'RssAction'
]
];
}

ну и собственно в своем расширении мне не нужно париться насчет поданных моделей - конечный разработчик сам создаст что нужно, имплементирует.
Мог где-то ошибиться, но смысл понятен. Правда тут больше об IoC, чем о di.

для сравнения как я это реализовывал это год назад https://github.com/zelenin/yii2-rss#usage
в массиве $items делал маппинг, что в принципе тоже перекладывание ответственности на плечи конечного разработчика, но сам по себе подход немного другой.

[zelenin]

считай, полностью написал расширение)

[samdark]

я писал: когда тебе интересен yii, ты не знаешь как применить di, а когда знаешь как его применить, yii перестает быть интересен) имхо, не повод для споров.

Вообще инструмент и не должен быть интересен. В идеале он должен быть изучен от и до и больше не представлять интереса в качестве предмета для изучения. Разве что для улучшения...

[zelenin]

http://blog.revathskumar.com/2015/08/ph ... asses.html - сервисы в yii
http://den.bz/article/using-interfaces- ... n-php.html - интерфейсы в контексте ioc
http://kristopherwilson.com/2013/07/04/ ... re-in-php/ - луковичная архитектура

[ElisDN]

В контексте статьи весьма актуально: https://www.youtube.com/watch?v=_0LwQ2qESws

[lynicidn]

круто =)

[nepster]

круто =)

нет это не круто. Это медленно избыточно и напоминает свалку (нужно прибрать).
Плюс у этого докладчика явные проблемы с датами и деньгами.

[zelenin]

нет это не круто. Это медленно избыточно и напоминает свалку (нужно прибрать).

это ddd

Плюс у этого докладчика явные проблемы с датами и деньгами.

а у авторов книг про mvc проблемы с автомобилями, моторами и зажиганием.

[ShNURoK]

По теме плаваю, но выскажусь. Тема интересная, неплохо было бы как-то описать, что для чего необходимо, так как судя из доклада, ссылку на который давали, своими словами, такие системы надо заранее проектировать, иначе потом будет сложно изменить архитектуру. Это если я еще все правильно понял.
Также я не понимаю, зачем нужно прикручивать репозиторий? Опять же, я не секу фишку, но ИМХО более 90% разработчиков не пишут интерфейсы и особо не задумываются о расширении функционала сторонними разработчиками. Нет, я согласен, что надо, и надо тесты, но реальность в обществе yii другая.
Я перешел с ZF1 на yii1, так вот у них на форуме тоже тогда тема была, про DataMapper и все мечтали о sf Еще помню, что осуждали валидацию, блин уже не помню, но помоему у них она не в моделях была. Если не ошибаюсь отдельный слой.
Так вот, если такое большое желание писать интерфейсы и делать малосвязанные компоненты, то надо ИМХО валить на sf, так как в итоге, все эти паттерны и размер, сложность приложения приведут к тому, что от yii ничего не останется и он будет только тянуть в свое болото.
Все выше, это ИМХО и вообще без какой-либо практической базы.

Хотел спросить еще вот о чем, тоже слой, кто что думает по повод viewModel, мне кажется это необходимо, так как в моем говнокоде логика утекает во view и фреймворк вроде как содействует. В zf были viewHelper, а здесь чего-то такого не хватает. Вот пример для ларавел https://github.com/laravel-auto-present ... -presenter

[zelenin]

По теме плаваю, но выскажусь. Тема интересная, неплохо было бы как-то описать, что для чего необходимо, так как судя из доклада, ссылку на который давали, своими словами, такие системы надо заранее проектировать, иначе потом будет сложно изменить архитектуру. Это если я еще все правильно понял.
Также я не понимаю, зачем нужно прикручивать репозиторий? Опять же, я не секу фишку, но ИМХО более 90% разработчиков не пишут интерфейсы и особо не задумываются о расширении функционала сторонними разработчиками. Нет, я согласен, что надо, и надо тесты, но реальность в обществе yii другая.
Я перешел с ZF1 на yii1, так вот у них на форуме тоже тогда тема была, про DataMapper и все мечтали о sf Еще помню, что осуждали валидацию, блин уже не помню, но помоему у них она не в моделях была. Если не ошибаюсь отдельный слой.
Так вот, если такое большое желание писать интерфейсы и делать малосвязанные компоненты, то надо ИМХО валить на sf, так как в итоге, все эти паттерны и размер, сложность приложения приведут к тому, что от yii ничего не останется и он будет только тянуть в свое болото.
Все выше, это ИМХО и вообще без какой-либо практической базы.

собственно выше я высказался в таком же ключе - yii сам подталкивает к говнокоду. если ты начнешь писать по ddd, тебе придется все разрабатывать с нуля, практически не используя и заменяя родные компоненты yii. А тогда зачем оно нужно? symfony+doctrine решают.
Да плюса - простота и соответственно быстродействие.
Интерфейсы кстати не совсем напрямую соответствуют ddd. То есть писать их можно и нужно и без ddd - это просто вопрос понимания разработчиком процессов.

Хотел спросить еще вот о чем, тоже слой, кто что думает по повод viewModel, мне кажется это необходимо, так как в моем говнокоде логика утекает во view и фреймворк вроде как содействует. В zf были viewHelper, а здесь чего-то такого не хватает. Вот пример для ларавел https://github.com/laravel-auto-present ... -presenter

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

[yan]

Хотел спросить еще вот о чем, тоже слой, кто что думает по повод viewModel, мне кажется это необходимо, так как в моем говнокоде логика утекает во view и фреймворк вроде как содействует. В zf были viewHelper, а здесь чего-то такого не хватает. Вот пример для ларавел https://github.com/laravel-auto-present ... -presenter

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

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

[zelenin]

Хотел спросить еще вот о чем, тоже слой, кто что думает по повод viewModel, мне кажется это необходимо, так как в моем говнокоде логика утекает во view и фреймворк вроде как содействует. В zf были viewHelper, а здесь чего-то такого не хватает. Вот пример для ларавел https://github.com/laravel-auto-present ... -presenter

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

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

некрасиво, а главное не очевидно. лучше все-таки юзать пример выше.

[yan]

некрасиво

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

а главное не очевидно. лучше все-таки юзать пример выше.

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

[zelenin]

некрасиво

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

неудобно для человека, не знающего что искать. Гораздо очевиднее, все параметры передать в прослойку в виде ViewModel, там обработать, и передать дальше, во вьюху. Любой новичок сразу увидит, что происходит. К тому же это известный паттерн, а не свой костыль.

[nepster]

Ребята, если пытаться применять ддд или подходы других фрайворков, то от yii2 ничего не остается, это я уже проверил.

Поэтому либо пишите в стиле yii2 либо берите другой инструмент.