и там делать save

так ты будешь мапить сущности на ar

не надо мэпить сущности на ar

делается все проще

не надо мэпить сущности на ar

но можно!)

точнее

class Product { private $data; // ProductModel }

что-то в этом духе

и вот тут Product это уже будет сущность

а ProductModel просто property-bag, стэйт агрегата

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

хз

можно делать так

можно не юзать AR

class Product { public function __construct(ProductBuilder $builder) { $this->raise(new ProductAdded(/** data */)); } }

и потом подписываться на ивенты и уже черз ar мэпить)

и ProductAdded можно делать как AR модельку

надо raise как-то имплементить)

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

Хотя с другой стороны, один черт, этой логики не должно быть в контроллере

я не понял сути вопроса

Я к тому, что когда обновляешь запись, тот код который я привел выше может сильно разрастись (на больших таблицах особенно) и он просится, чтобы его куда-то вынесли. Но после выноса, он переиспользован, скорее всего, не будет.

Я к тому, что когда обновляешь запись, тот код который я привел выше может сильно разрастись (на больших таблицах особенно) и он просится, чтобы его куда-то вынесли. Но после выноса, он переиспользован, скорее всего, не будет.

на каких таблицах, у тебя же сущности

ну то есть я не понимаю что и зачем ты вообще делаешь

возьми orientdb и работаю напрямую с агрегатами

без херни с SQL

с большими сущностями особенно*

с большими сущностями особенно*

большие сущности - это много полей? или очень жирные агрегаты?

ну то есть у меня вопрос к декомпозиции

много полей

много полей - не проблема

делаешь value object-ы

и радуешься

апдейт - заменя одного VO на другой

то есть любой апдейт предвращается в инстанцирование объекта

в итоге логика "добавления" и "апдейта" сильно унифицируется

и со связями проблем нет?

опять я в рамках реляционки говорю )

связи - это просто поля объектов

ну то есть какая разница string там или object или object[]

это просто стэйт

я не понимю твоих загонов

и что ты хочешь по итогу иметь

какую ты цель приследуешь

разницы нет, только чуть больше гемора при заполнении сущности

разницы нет, только чуть больше гемора при заполнении сущности

разницы с чем?

о чем ты?

я просто уже потерял нить разговора

))

ты хочешь сделать data mapper + uow поверх eloquent?

в этом нет смысла

ты хочешь сделать data mapper + uow поверх eloquent?

в точку

хотел

теперь уже не хочу, когда поговорили о доктрине

хотел

зачем?)

теперь буду выкидывать свои persistense репозитории и переводить весь проект на доктрину

ну то есть опять же - какую цель ты приследовал этим желанием?

теперь буду выкидывать свои persistense репозитории и переводить весь проект на доктрину

опять же зачем

ну то есть опять же - какую цель ты приследовал этим желанием?

тестируемость без участия бд

тестируемость без участия бд

ты уверен что окупится?

ну то есть сделать тупо in-memory базу данных где все гоняется быстро

ты уверен что окупится?

неа, но eloquent мне постоянно вставляет палки в колеса

это уже по другой теме, а не то, что мы тут обсуждаем

Кстати, если использовать репозитории с eloquent без апдейтов, то апдейты будут размазаны где только не лень используя orm напрямую

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

неа, но eloquent мне постоянно вставляет палки в колеса

Юзай query builder :)

ERROR: S client not available

Кстати, если использовать репозитории с eloquent без апдейтов, то апдейты будут размазаны где только не лень используя orm напрямую

Разве ?

Разве ?

ну да, в контроллерах, командах, сервисах

ну да, в контроллерах, командах, сервисах

Хм, у меня работа с базой в одной папке. По типу: Папка подпапки (юзер, комментарии и т.п). В каждой подпапке есть файл который отвечает полностью за работу с базой. Сама "база" внедряется с помощью DI, а методы хранятся вообще в другом месте (Но там что-то типа делегирования). Вроде бы не плохо Не знаю, поймешь или нет

Хм, у меня работа с базой в одной папке. По типу: Папка подпапки (юзер, комментарии и т.п). В каждой подпапке есть файл который отвечает полностью за работу с базой. Сама "база" внедряется с помощью DI, а методы хранятся вообще в другом месте (Но там что-то типа делегирования). Вроде бы не плохо Не знаю, поймешь или нет

Аналогично, правда в контроллерах/коммандах я внедряю интерфейс репозитория, который уже работает с Eloquent.

А Eloquent ну нахер, я переходил с query builder'a на это, посидел пару месяцев и свалил. Связи удобная штука ( в плане кода), но потом по откладке (и еще кое-что) жопа. Тем более, что я могу сделать так

И не нужны джоины )

И связи тоже

Аналогично, правда в контроллерах/коммандах я внедряю интерфейс репозитория, который уже работает с Eloquent.

В контроллерах я просто беру провайдер app()->make('name') и вызываю его методы, это все что могут эти контроллеры) А модели я кинул в папку app\eloquent, там сейчас ничего кроме свойств (аля hidden, name и т.п).

Выше на скрине image ($this->image) - и есть класс App\Eloquent\Image

Выше на скрине image ($this->image) - и есть класс App\Eloquent\Image

это чем-то и напоминает репозиторий

Практически он ?

В общем: App\Eloquent\Class - чисто extends Eloquent Папка - подпапки - сущность . Тут через DI внедряю класс из папки eloquent и пишу делегаторы. Вон как выше И еще одна папка с подпапками - сущность: тут я через DI внедряю нужный мне выше класс, ну и описываю логику

Все это через провайдер. Ну и контроллер "хавает" последнее

Только не знаю как поступать с некоторыми частями системы которые не особо относятся к сайту. Например: сервис для работы с токеном. По логике его не нужно пихать как я делаю это выше, а как описывать - фиг знает, еще не думал

> Только не знаю как поступать с некоторыми частями системы которые не особо относятся к сайту. вынести в композер пакет?

Если так поступать, то нужно делать "универсальную систему". Я изначально думал дергать токен юзера с помощью готового средства в самой системе, то есть: зависимость. Я не думал насчет этого еще если честно, но вариант хороший, спасибо )

Коллеги, разрешите похвастаться, второй том Elegant Objects наконец закончен и уже в продаже на Амазоне: http://amzn.to/2oW9qk4 Будет доступен доставкой по странам СНГ через две недели. Пишите на shop@yegor256.com

Будет ли на русском языке ???

Зачем?

Чтобы такие неграмотные как я тоже могли прочитать )

К сожалению бегло читать по английски не удается...

Но когда надо перевожу статьи для себя

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

NoNullMoney )))

PlusMoney ))

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

А чем не кошелек? а ноль может быть?

А чем не кошелек? а ноль может быть?

кошелек это какая-то сущность)

ну как-то связь между тем, что денег больше 0 и кошелек не оч очевидна

Ну деньги как таковые не могут иметь сумму, они могут иметь номинал

Cash

Cash

Да хорошая метафора:)