Как стать автором
Обновить
3
Карма
0
Рейтинг

Пользователь

  • Подписчики
  • Подписки

Поговорим о Yii 2

Либо я что-то не понимаю сам, либо не понимаю вас. В прокси классах юзается отдельная фабрика, в которую отдельно передаются EM и метаданные

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L124

Эти две штуки вроде особо не связаны и в комментах к интерфейсу прямо написано, что он используется для построения

to implement ActiveRecord functionality on top of the persistence-ignorance that Doctrine propagates

https://github.com/doctrine/common/blob/2.4/lib/Doctrine/Common/Persistence/ObjectManagerAware.php#L29

Поговорим о Yii 2

Ну, тогда это уже привет data mapper, но идею понял, спасибо

Поговорим о Yii 2

Ну насколько я понимаю, суть претензии выше в том, что для того, чтобы интегрировать внешний код в Yii, приходится как раз таки эти обертки, прослойки и коннекторы реализовывать, просто чтобы подключить библиотеку. В симфони в принципе достаточно только описать класс для DI, а с версии 3.3 уже иногда и это можно не делать (для простых случаев).

Поговорим о Yii 2

Я правильно понимаю, что берется сторонний класс, для него делается репозитрий, который наследуется от AR? Но в таком случае разве репозиторий не будет возвращать инстансы самого репозитория вместо модели? или надо будет писать кастомную инстанциацию объектов?

Поговорим о Yii 2

ну, магический — это не совсем «соответствующий приватному свойству». Например, если оперировать терминами той же доктрины, то в свойствах связей toMany лежит обычно Collection, а геттер отдает массив для того, чтобы нельзя было эту коллекцию мутировать.

ясно, спасибо

Поговорим о Yii 2

В смысле внутренние и почему калечить? Это «изкоробочное» решение, на основе которого можно сделать свои методы активных моделей через какой-нибудь трейт

Но самому пользоваться еще не доводилось.

Поговорим о Yii 2

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


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

В симфони очень легко пишется независимая библиотека, к которой рядом (сверху) кладется бандл, семантическая конфигурация и расширение для DI. За примерами далеко ходить не надо — JmsSerializer + JmsSerializerBundle, DoctrineOrm + DoctrineBundle и тд. Делается очень просто все.

Поговорим о Yii 2

Эта возможность, кстати заложена в доктрине из коробки :)

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

Поговорим о Yii 2

А можно пример? Это какие то отдельные валидаторы? или работает через магический геттер? Потому что в коде по ссылке выше идет прямое обращение к атрибуту

Поговорим о Yii 2

Ну я это написал к тому, что не завязывать модели на актив-рекорд не получится. Кстати доктрина позволяет организовать ActiveRecord-like работу

Поговорим о Yii 2

А можно использовать в качестве модели сторонний класс, который не унаследован от иерархии актив-рекорд? Доктрина такое позволяет.

Поговорим о Yii 2

Идеальный ответ — никак. Я бы хотел наложить валидатор на метод в таком случае.

Если простым путем — через рефлексию

Если универсально, то вот https://symfony.com/doc/current/components/property_access.html, штука сама выберает, как обратиться к свойству, через метод, магию или публичный доступ

Поговорим о Yii 2

Ну, тут очевидная разница в том, что ваш пример — это глобалы, за которые в приличных конторах бьют линейкой по рукам, и это надо сделать специально, а в Yii — это by design. До глобалов на самом деле не видел, чтобы доходили.

Поговорим о Yii 2

Меня лично всего меня вымораживает то, что все встроенные валидаторы требуют, чтобы проперти были не ниже, чем protected, иначе ни публичного доступа нет, ни встроенные __get __set до них не доберутся

Поговорим о Yii 2

<zanuda>
s/persist/flush/
</zanuda>


Большая разница в том, что в Yii можно тут сделать что угодно, имея в прямом доступе все компоненты системы через статику, а при работе с symfony+doctrine вы сможете обращаться только к доменной логике (логике модели и ее связей)

Symfony 4: структура приложения

В списке вы упомянули только приемочные, но при этом делите эти тесты, так что я решил уточнить на всякий случай. Спасибо за объяснение.

test — очень похоже на dev но ориентируется на приемочные тесты.

А вот интеграционные/приемочные тесты — ...

Symfony 4: структура приложения

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

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

Symfony 4: структура приложения

А на каком из ваших env вы производите интеграционное тестирование?

Symfony 4: структура приложения

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

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

Symfony 4: структура приложения

навязывать папку src — это имхо что выкидывать psr-4. плохо ложится на концепцию монорепозиториев, которые потом делят на пакеты через subtree. при том, что у нас есть такая крутая вещь, как композер — описывать структуры файлов можно и в нем (где конфиги лежат, где сурсы итд)

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность