Yii Framework

anton_z писал(а): ↑2017.10.20, 02:27 но вот тут решился поделиться с сообществом и получить конструктивные замечания, быть может, я что-то упустил.

maleks писал(а): ↑2017.10.20, 13:25Тут они походу более строги и AR дальше репозиториев не высовывают, а у вас спокойно возвращаются AR объекта из репозиториев.

zelenin писал(а): ↑2017.10.20, 13:47 Первый вариант выйдет боком сразу как тебе надо будет написать функциональность за 2 часа до конца рабочего дня.

zelenin писал(а): ↑2017.10.20, 13:47 AR все равно глобально доступен, поэтому либо ты кроме программных контрактов репозиториев используешь внутрикомандные договоренности либо не используешь AR

maleks писал(а): ↑2017.10.20, 14:17

zelenin писал(а): ↑2017.10.20, 13:47 Первый вариант выйдет боком сразу как тебе надо будет написать функциональность за 2 часа до конца рабочего дня.

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

anton_z писал(а): ↑2017.10.20, 14:35

zelenin писал(а): ↑2017.10.20, 13:47 AR все равно глобально доступен, поэтому либо ты кроме программных контрактов репозиториев используешь внутрикомандные договоренности либо не используешь AR

Сложно нвйти проект, в котором бы не использовались внутрикомандные договоренности. Без них нет коллективной работы, а без коллективной работы и нет проекта.

anton_z писал(а): ↑2017.10.20, 14:35А почему обязательно глобально? AR бывает и такойhttps://docs.zendframework.com/zend-db/ ... le-objects.

zelenin писал(а): ↑2017.10.20, 14:52могла бы существовать и без AR.

zelenin писал(а): ↑2017.10.20, 15:04

anton_z писал(а): ↑2017.10.20, 15:13 Это очень важное отличие. Пожалуйста, поясните, что будет глобального.

anton_z писал(а): ↑2017.10.20, 15:43 Ну 2 в 1 и глобальность никак не связаны

anton_z писал(а): ↑2017.10.20, 15:43База через этот класс не доступна, нет адаптера, в отличие от yii/laravel, а где его взять?

anton_z писал(а): ↑2017.10.20, 15:43 Можно создать шлюз к таблице и получать из него шлюзы к строкам, а шлюз к таблице из контейнера, в котором будет и объект адаптера. Глобальности как раз тут можно избежать, так как нет статики.

Faeron писал(а): ↑2017.10.20, 16:25 Правильно ли понимаю, что если решил использовать в проекте Doctrine, то все модели должны быть спроектированы с этим учетом ("завязаны" на нее)?

Т.е. по сути получается сущности домена = сущность доктрины?

zelenin писал(а): ↑2017.10.20, 15:50 статика для глобальности не нужна. (new Article)->find($id); из любого места приложения.
в yii1 кстати Article::model() был именно оберткой над (new Article) в виде (new CActiveRecord('Article')) - как то так.

anton_z писал(а): ↑2017.10.21, 03:44
Не поспоришь, объект почти любого класса досупен для создания в любом месте системы, через оператор new. Дело в зависимостях, необходимых для создания объекта. Если подключение доступно статичеcки, да, AR можно создать в любом месте системы. А если коннекшен нельзя получить где угодно, то и AR где угодно создать не получится

zelenin писал(а): ↑2017.10.21, 04:04 Но все же начали мы обсуждение c yii/eloquent вариантов. Вряд ли кто-то будет использовать ar не этих двух реализаций.

anton_z писал(а): ↑2017.10.14, 03:57 По поводу списания с баланса по событиям (Eventual Consistency) - это все очень опасно. Допустим у вас пиковая нагрузка и все воркеры заняты, ну или вообще воркеры недоступны по какой-то причине (сеть, сервер и пр.). Пользователь производит оформление, а событие еще не обработано. Пользователь может увидеть, что деньги не списались и оформить еще один или несколько заказов до первого списания. Как будете разруливать? Как объяснить пользователю, почему система дала ему оформить еще один заказ? Транзакции прекрасно решают эту задачу. Без них решить ее может и можно, но лекарство окажется хуже болезни - сложно все станет. Интернет-магазины не такие уж сложные приложения, нет там такой логики, чтобы DDD применять. Они прекрасно делались и работали до изобретения всех этих DDD и ES.