То есть в такой схеме сущность состоит из множетсва классов, сама струтура данных и её действия, в которых уже зашита логика. Это меня спасает от разбухания модели,

Ага, есть геттеры

а сеттеров нет?

это зависит от самой сущности

Если есть такая необходимость, то могут быть сеттеры

а что за необходимость?

) Если она позволяет изменять свое состояние из вне)

ну вот когда есть такая необходимость?

что бы установить какое то свойство модели)

Нужен конкретный пример?

ага

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

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

смешаешь бизнес-транзакцию и обработку реквеста\респонса

ок, теперь ясно, но коллеги не поддержат в этом плане, они на меня взъелись, даже когда я предложил все, что зависит от реализации стораджа, вынести в репозитории из сервисов

ну отделять выбор типа от реализации типа хорошая практика

фабрики там)

да им похер, они говорят, что многакласов!!!1111!!11

это хорошо

у вас должно быть много маленьких классов

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

вариант с дабл диспатчем мне больше нравится, чем с ивентами - более явные зависимости

ага

Оккееей) Ну вот пример. Есть модель которая хранит в себе состояние изображения, в конструктор передаем имя исходной картинки. С помощью геттеров получаем свойства изображения (высота, ширина, цветовую схему итд), но изменять мы можем только масштаб картинки, поэтому будет только один сеттер setScale(), а высоту и ширину менять нельзя).

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

кто то не читал первую главу эванса и сразу читал вторую

кто то не читал первую главу эванса и сразу читал вторую

типа того, только я прочитал главы 3 и 1я уже почти полностью забылась :)

кто то не читал первую главу эванса и сразу читал вторую

А можно подробнее про эту книгу?

Или сразу фб2 :)

А можно подробнее про эту книгу?

domain driven design by eric evans

но ее читать без понимания ООД вредно, я до сих пор ее плохо понимаю(

при этом с каждым годом становится понятнее и понятнее

Или сразу фб2 :)

техническую литературу читают в пдф - там же картинки, код, схемы. а в fb2 ее обычно и нет.

да не, там можно подцепить их

но эванса все равно нет в mobi/epub/fb2

есть DDD Quickly зато в этих форматах

с ивентами не было бы лишнего аргумента и было бы что-то типа $this->recordThat(ItemBought::forUserWithItem($user, $item));

скинул чувакам этот пример, начали спрашивать, что примерно должно происходить в "покупателе", и как без сеттеров менять приватные поля модели :D

второй вопрос хорош, спроси зачем им сеттеры, почему поля не публичные?

если при сеттинге какие-то дополнительные действия должны происходить

тогда это не сеттинг

проверка баланса например

в сеттере должен быть метод

очевидно же

например rename()

это уже логика

а не setName

да, типа того

семантика ваще разная)

setPassword() -> changePassword()

только тогда симфони формс у вас отвалятся :D

setPassword() -> changePassword()

и инжектить в него объект Password

))

только тогда симфони формс у вас отвалятся :D

для форм DTO отлично идет

с сеттерами-геттерами))

ну да.. если ранее были сеттеры, то отвалятся формы )

с сеттерами-геттерами))

с публичными полями, пф

если формы были в сущности, то вы уже все делали неправильно

бля...и правда...

А что симфони завставляет юзать одну модель для всего?) Ужс нах

не заставляет, но почему-то все пихают сущность в форму

что такое одна модель я не уловил, но наверное это один объект...

А понял, фуух

из бест практикс потому что

кек, у нас на фронте ангуляр, нас не колышат формы слава б-гу :D

админка?

не, просто бэк работает как рест апи

админка тоже на ангуляре? )

что такое одна модель я не уловил, но наверное это один объект...

ну читай как один объект) Который умеет делать все все на свете)

там твиг только для профайлера работает)

у всех реакты, ангуляры, вокруг одни SPA. а по факту куда не плюнь везде серверный рендеринг

ERROR: S client not available

хехе ага )

всем привет, куда ни плюнь везде жквери по факту )

к вопросу о сеттерах в ентити, чем плох public function setAccount( Account $account) { $this->account = $account; }

я так и не понял

вешать на мапер аля энтити бизнес логику , имхо не совсем правильно

да ничем

у всех реакты, ангуляры, вокруг одни SPA. а по факту куда не плюнь везде серверный рендеринг

реакты тож серверный рендеринг

это даже фича

)

есть те у кого "еще" серверный рендеринг, а есть те у кого "уже" серверный рендеринг ))

к вопросу о сеттерах в ентити, чем плох public function setAccount( Account $account) { $this->account = $account; }

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

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

А в чем разница?

к вопросу о сеттерах в ентити, чем плох public function setAccount( Account $account) { $this->account = $account; }

в каких случаях тебе надо делать setAccount?

что это за операция такая?

доктрине надо)

нет, лол

присваиваешь конкретную энтити аккаунта на что-нить , аля пеймент

или меняешь

окей давай назовем updateAccount()

или changeAccount

так когда у тебя в приложении это происходит? Любой пользователь любому может сделать этот set?

сути дела не изменит

семантика совсем разная ж)

это я уже ограничу выше на уровне сервиса

суть в том, что идея Антона была делать метод update(array $data) и внутри уже педалить через $this->

ну грубо говоря, заче вам сеттер? Сделайте поле публичным

чем он лучше чем отдельный сет на каждое поле ?

затем, чтобы провенить данные по типу на входе

как у паблик проперти проверить , что туда пихнули именно объект Account?

использовать Hack :C

но это все, что вам нужно проверять?

не, тут вопрос в подходе