Ты тоже используешь DoctrineExtension?

Сейчас попробую отключить timestampable. Он у меня всего в одной модели используется. Так что...

Сейчас попробую отключить timestampable. Он у меня всего в одной модели используется. Так что...

просто объясни зачем тебе оно?)

Минута делов

мне как-то достался проект где вот этого минутного дела набиралось на 80 лишних запросов) и только половина потому что "кто-то любит миграции руками писать". Остальное - какие-то баги вызванные кривым обновлением dbal

На тот момент, мне казалось, что я часто буду юзать его. И кинул до кучи, когда экстеншены выбирал. А потом забыл... ну или забил..

Я скажу так что ранее юзал GEDMO, сейчая KnpLabs/DoctrineBehaviors и все равно эта фигня появляется

Нет, проблема не в этом

хм... зато по пути поотключал еще пару бесполезных расширений )

Нет, проблема не в этом

Может быть, не разбирался, особо не напрягает так сильно что бы фиксить. Но помоему начинает эта хрень появляется именно после начала использования Doctrine extension. Хз может ошибаюсь. Я уж привык уже к автообновляемым полям и к проблемке хотя больше нуждался в translatable trait из вышеуказанного пакета.

Всем спасибо за сочувствие ) Пойду крыть матом окрамиуса и его прихвостней )

ребят, привет всем. я еще разок спрошу: есть нормально где почитать про webpack-encore? когда assetic использовал всё предельно ясно было, а вот с энкором не пойму ничего... например как ему в css указывать пути к шрифтам/картинкам?

Нашел пару нюансов для себя в использовании webpack-encore. 1 - отсутстиве поддержки вебпака 4. И врядли в ближайшее время предвидится. 2 - если используешь где-то какие-либо изображения например, которые не импортятся нигде в твоих описанных в конфиге entry - они тупо не войдут в билд. Либо импортить какждое в любом js файле из entry, либо костыли в виде CopyWebpackPlugin

Это не костыль а именно способ для этого.

Ну даже не знаю, что скзаать. Где-то в ишьюас на гитхабе вроде видел, что просили добавить поддержку такого, но ответ разрабточиков был прост " делайте import(./images/image.png) в вашем main.js"

Вот это похоже на костыль. :))

Да)

Поддержку вебпака 4 тоже не обещают. Ищут людей кто возьмется запилить поддержку вебпака 2/3/4 одновременно

А вообще энкор этот просто дает на выходе минимальный конфиг для вебпака. Так что у себя просто написал его свой и юзаю вебпак 4

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

а если картинка в цсс то на этапе сборки ее надо в билд сложить с CopyWebpackPlugin да

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

может ты не хочешь чтоб твои картинки из цсс складывались как файлики в билд а инжектились как base64

модульно же все норм)

по поводу геттеров/сеттеров в доктрине: http://doctrine-orm.readthedocs.io/en/latest/tutorials/getting-started.html

немного обновили доку что бы чуть соответстовало best practice (текст, не код)

немного обновили доку что бы чуть соответстовало best practice (текст, не код)

?

интересно единый язык в сущностях, считается за сеттеры ?)

интересно единый язык в сущностях, считается за сеттеры ?)

че?)

поясни мысль

я про семантику и Ubiquitous Language

а причем тут сеттеры?

единый язык как раз таки должен подстегивать тебя к нормальному моделированию)

и да, это сложно)

@thatside вот еще видяшки на тему SOA - думаю будет интересно http://udidahan.com/2015/02/02/finding-service-boundaries-illustrated-in-healthcare/

Ticket.assign(User) ticket.setUser(User)

в таком виде сеттеры больше похожи на конвенцию

если я не могу всем и вся рулить в конструкторе сущности, тобишь вот у меня сейчас на руках есть конкретная ситуация, есть легаси проект, увы не с нуля, который мы своими силами пытаемся причесать и сделать лучше, нежели было до нас с каждым днем, переходить полностью на ddd трудно, получается гибкость ценной сложности, и у нас некое промежуточное решение, есть VO,есть ActiveQuery, максимально все приближенно к языку бизнеса, без явных сеттеров(Set) семантики

типа "давай будем приписывать к параметру глагол set- и тогда будет понятно какие свойства объекта можно изменить"

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

если я не могу всем и вся рулить в конструкторе сущности, тобишь вот у меня сейчас на руках есть конкретная ситуация, есть легаси проект, увы не с нуля, который мы своими силами пытаемся причесать и сделать лучше, нежели было до нас с каждым днем, переходить полностью на ddd трудно, получается гибкость ценной сложности, и у нас некое промежуточное решение, есть VO,есть ActiveQuery, максимально все приближенно к языку бизнеса, без явных сеттеров(Set) семантики

типо явный профит отсюда, когда заводится таск сделать то и то, можно буквально ctrl+f поиск по проекту сделать и найти нужное место, которе следует поменять

Ticket.assign(User) ticket.setUser(User)

1. setUser тут не нужен (разве что ты про ограничения что нельзя односторонние one-to-many 2. наличие setUser как бы говорит что ты забил на Ub Language

в таком виде сеттеры больше похожи на конвенцию

если их юзать с анемией то да и какой смысл?)

1. setUser тут не нужен (разве что ты про ограничения что нельзя односторонние one-to-many 2. наличие setUser как бы говорит что ты забил на Ub Language

так во тя ж и спрашиваю, первый вариант, тот который юзается у нас

а assign это просто метод, не сеттер. У этого метода есть семантика и все такое

второй — тот, от которого мы ушли, мы попадаем под doctrine without setters ?)

или исключительно через конструтор :)

если их юзать с анемией то да и какой смысл?)

анемией? ) сорян не понял слово в контексте

второй — тот, от которого мы ушли, мы попадаем под doctrine without setters ?)

блин чел, сеттер или геттер - это некий метод который подразумевает доступ к полю объекта. Точка. Если метод делает что-то иное или его имя не подразумевает прямую мутацию - это просто метод. Если он называется setName но делает больше чем сэтит имя - мы просто говорим о херово названных методах.

анемией? ) сорян не понял слово в контексте

"анемичная модель" - модель без поведения. Ну то есть объект который совокупность данных и функций по работе с этими данными но без этих самых функций, только эксессоры)

блин чел, сеттер или геттер - это некий метод который подразумевает доступ к полю объекта. Точка. Если метод делает что-то иное или его имя не подразумевает прямую мутацию - это просто метод. Если он называется setName но делает больше чем сэтит имя - мы просто говорим о херово названных методах.

я же с самого начала сказал, что я говорю за семантику

о черт зачем спросил )

анемией? ) сорян не понял слово в контексте

anemic model vs rich model там по ссылке пример анемичной модели

и описал профиты, которые как мы кажется, заимели с этого

я же с самого начала сказал, что я говорю за семантику

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

короч вся проблема в том что под сеттером понимается либо любой метод который называется setSomething или который в теле содержит $this->something = $something;

хотя это не так

сеттер это конвенция, эксоссор данных, то есть мутатор который явно говорит тебе "когда видишь setStatus то оно поменяет поле статуса у меня внутри

и проблем с этой конвенцией нет никаких

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

если вся бизнес транзакция подразумевает вызов setName - мы просто говорим о херово названном методе, не передащем семантику и единый язык, не более. Если для операции надо вызвать пяток сеттеров - мы говорим о высокой связанности.

если тебе бизнес говорит "we want to rename product" то у сущности Product должен быть метод rename.

мне кажется иногда цепляются именно к названию) можно и апдейтеров наделать )) но суть не в конвенции и названии

мне кажется иногда цепляются именно к названию) можно и апдейтеров наделать )) но суть не в конвенции и названии

ну потому что названия несут семантику. Я на 100% уверен что найдется кейс когда метод начинающийся с приставки set будет нести вполне внятную семантику в контексте операции. Но примеров таких я не видел)

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

если тебе бизнес говорит "we want to rename product" то у сущности Product должен быть метод rename.

мы хотим сменить ценник

changePrice тоже самое что и setPrice

ERROR: S client not available

changePrice тоже самое что и setPrice

вполне)

и если для этой операции тебе надо вызвать только один метод - не вопрос)

2 метода у одного и того же объекта да еще и в определенном порядке - уже можно насторожиться. 5 методов - явно что-то не так

2 метода у одного и того же объекта да еще и в определенном порядке - уже можно насторожиться. 5 методов - явно что-то не так

можешь привести пример, не могу понять как в такой простой операции могут появится 2 метода

changePrice тоже самое что и setPrice

интересный факт, set и get не являются антонимами)

так операция бывает либо над объектом либо сам объект что то над собой делает. в этом все дело?

так операция бывает либо над объектом либо сам объект что то над собой делает. в этом все дело?

изменение цены? может повлечь отключение скидки)

если на дешевые не предусмотрен скидос

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

так операция бывает либо над объектом либо сам объект что то над собой делает. в этом все дело?

Да, идея в том что ты просишь объект что-то сделать а он сам разберется. Это и есть инкапсуляция, сокрытие информации, это ведет к снижению связанности и т.д.

т.е. сделаем 1 метод на 5 параметров

изменение цены? может повлечь отключение скидки)

ну например да

@fes0r, к сожалению, лодка этой прекрасной семантической модели вдребезги разбивается о скалы реального кода и реальных потребностей. Например, у меня есть гидратор, который строит дерево моделей из прилетевшего через graphql json. Казалось бы тут самое место анемичным моделям. Но нет, у меня достаточно логики скрытой за сеттерами. И ничего, живу. Думаю вот выложить гидратор пакетом... очень удобный получился.

т.е. сделаем 1 метод на 5 параметров

да, начнем с этого. Затем вспомним завет дяди боба что неприлично методу иметь более 3-х аргументов (в идеале вообще без аргументов, этому к слову есть опять же обоснование с точки зрения связанности).

мне так кажется в итоге

приходим к тому чтобы сделать n*2 разных методов для разных комбинаций свойств

вместо просто n сеттеров по отдельности

интересный факт, set и get не являются антонимами)

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

а то null передавать в метод так то тоже не семантика )

приходим к тому чтобы сделать n*2 разных методов для разных комбинаций свойств

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

т.е. раздувать код промежуточными объектами

вместо просто n сеттеров по отдельности

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

разные методы скорее всего там

@fes0r, к сожалению, лодка этой прекрасной семантической модели вдребезги разбивается о скалы реального кода и реальных потребностей. Например, у меня есть гидратор, который строит дерево моделей из прилетевшего через graphql json. Казалось бы тут самое место анемичным моделям. Но нет, у меня достаточно логики скрытой за сеттерами. И ничего, живу. Думаю вот выложить гидратор пакетом... очень удобный получился.

давай проясним. Ты говоришь о "десериализации json в сущности" или что? причем тут гидраторы? Я понимаю там на чтение но причем тут сеттеры и анемичные модели?

т.е. раздувать код промежуточными объектами

на практике кода либо столько же либо даже меньше становится

ты просто не учитываешь количество кода всяких там сервисов-менеджеров которые мутируют сущности

ну и еще - там куча других вопросов всплывают, как дробить на сущности, как выделять границы.... и это нихера не простые вопросы)

именно по этой причине большинство не загоняются и лепят анемичные модели) не потому что "так правильно" а потому что это зона комфорта.... не надо думать... все просто и понятно

подумаешь что это просто процедурное программирование + чуть чуть изоляции стэйта...

о блин приклеилось новое слово )

вместо просто n сеттеров по отдельности

у меня есть стойкое подозрение что все эти стериотипы и непонимание происходят из одной простой вещи - люди часто делают декомпозицию по UI