ну статический метод

зачем лишний объект в этой цепочке?

Тут еещ такой момент, сейчас при добавлеении нового поля, мне нужно: Описать свойство Описать гетер и сетер ДОбавить его в CRU(D) кнтроллера Добавить в CRU(D) сервиса и в сервисе обработать уже содание объектов итуда прокинуть свойства

зачем гетер и сетер? что значит описать свойства? Что за crud сервис?

зачем лишний объект в этой цепочке?

Ну как бы json to dto занимаются в основном фрэймворки

json в объект\хешмап делает фремйворк

ну а дальше че плодить слои

зачем гетер и сетер? что значит описать свойства? Что за crud сервис?

Про геттеры и сеттеры я помню твою позицию, но пока я её полностью не пойму, я не смогу её начать лобировать на совем проекте. Оисать свойство имею ввиду просто добавить его в объект(ну и в моем случае указать аннотации). Ну а под CRUD интересует операции создания и изменения, которые принимают дохера параметров

У тебя модель берёт на себя лишнюю ответственность.

Чем чище модель - тем лучше.

что значит “чище”?

Про геттеры и сеттеры я помню твою позицию, но пока я её полностью не пойму, я не смогу её начать лобировать на совем проекте. Оисать свойство имею ввиду просто добавить его в объект(ну и в моем случае указать аннотации). Ну а под CRUD интересует операции создания и изменения, которые принимают дохера параметров

это нарушение инкапсуляции и плевок в сторону information hiding

Чем чище модель - тем лучше.

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

У тебя модель берёт на себя лишнюю ответственность.

сейчас в ней только свойства и сеттеры геттеры, конкретно в классе Entit 'ей

Про геттеры и сеттеры я помню твою позицию, но пока я её полностью не пойму, я не смогу её начать лобировать на совем проекте. Оисать свойство имею ввиду просто добавить его в объект(ну и в моем случае указать аннотации). Ну а под CRUD интересует операции создания и изменения, которые принимают дохера параметров

про crud ничего не понял, геттер и сеттер ты сам решил добавлять, ну а поле в объект надо прописывать, да

кароче давайте репу на гитхабе

что значит “чище”?

Значит делает только работу, для которой она и была создана. Бизнес логика если это домен

и каждый свой трушный вариант напишет)

и будем сраться в пулл реквестах)

Значит делает только работу, для которой она и была создана. Бизнес логика если это домен

как-то ниочем

Значит делает только работу, для которой она и была создана. Бизнес логика если это домен

ну вот кто устанавливает рамки этой логики?)

про crud ничего не понял, геттер и сеттер ты сам решил добавлять, ну а поле в объект надо прописывать, да

updateEntity(Entuty $entity, $newEntityParam1, $newEntityParam2 и т.д)

зачем лишний объект в этой цепочке?

+

лол развидеть это

ну вот кто устанавливает рамки этой логики?)

Бизнес)

Entity.fromArray(arrayFromJson)

а нет ниего плохого что массив в параметрах?

если аменить его на dto будет автодополнение

так как ты создашь dto ?)

+ когда в пыхе будет тайпхинтинг для полей, то еще плюшки будут

так как ты создашь dto ?)

пока никак)

это мы с тетсировщиком придумал схему сегодня

foreach в контроллер

Бизнес)

ты слишком абстрактно вещаешь.

пока никак)

этот метод на выходе тебе даст сущность формы

а нет ниего плохого что массив в параметрах?

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

нет и нет

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

ты слишком абстрактно вещаешь.

"как-то ниочем" я то?))

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

не понял что в фориче делать

вот есть массив с ебанутыми названиями элементов

не понял что в фориче делать

да про foreach сарказм

ахах

@mkusher имхо норм вариант говорит, я согласен

слава богу что я заподозрил что тчо то не так))

"как-то ниочем" я то?))

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

не такой уж я безнадежный

сделай сущность формы

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

или не понимаешь

там весь твой автокомплит и все знания за то что в форме

или не понимаешь

или не понимаю)

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

или консттруктор пусть массив сразу приниммает

если сделаешь статичный метод то по сути фабричный метод сделал для сущности

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

Ну раз понимаешь, зачем холивар разводить?) хочешь самоутвердиться - предложи самый оптимальный вариант а мы оценим :)

далее уже это сущность все делает

у нее будет метод getЧТОТебеНадо

Ну раз понимаешь, зачем холивар разводить?) хочешь самоутвердиться - предложи самый оптимальный вариант а мы оценим :)

ну если возвращаться к исходной задаче - я не юзаю DTO, я юзаю билдеры и фабрики.

и в контролере код будет примерно такой $result = CurseForm::fromArray($formArray)->getЧтоТебеНадо(зависимости если есть необходимость);

до этого юзал подходы с DTO, пробовал и DTO->toEntity и entity::fromDTO, и то и то так себе

проблема с тем что у тебя как бы либо DTO должно пренадлежать к тому же слою (fromDTO), либо размазывается все на два слоя (toEntity)

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

там весь твой автокомплит и все знания за то что в форме

а класс формы как создаваться будет

из массива?

а класс формы как создаваться будет

а зачем тебе ?

а формы - это уже сверху все.

возня с ним

ты его по сути замапил на сущность

у тебя уже сущность

ERROR: S client not available

готовая

логика того как замапить лежит в фабричном методе

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

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

но его не одобрили

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

звучит как-то сильно страшно

главное не делать over enginiring

лучше взять простой подход и если что потом его отрефакторить

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

главное не делать over enginiring

сейчас его ка краз нет, просто набор параметров половина из которых не нужны кочует из формы в констуктор через 3 слоя

Тебе нужно из json (другое представление данных) создать сущность. Dto, в данном случае описывает данные полученные в запросе, и создаёт на их основе сущность. Билдер антипаттерн. Если нужен Билдер - значит уменьшай размер сущности/ разбивай её. В итоге dto в данном случае это таже фабрика.

сейчас его ка краз нет, просто набор параметров половина из которых не нужны кочует из формы в констуктор через 3 слоя

а три слоя не оверинженеринг? есть просто вероятность что твои три слоя достаточно изолированы весьма мала. И есть риск оказаться в ситуации когда у тебя проект это лазанья. Когда изменение на одном уровне требует "прорезать" все слои

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

а три слоя не оверинженеринг? есть просто вероятность что твои три слоя достаточно изолированы весьма мала. И есть риск оказаться в ситуации когда у тебя проект это лазанья. Когда изменение на одном уровне требует "прорезать" все слои

+

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

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

Д - декомпозиция

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

и как используются

"то что используется вместе - ложим вместе, что используется отдельно - ложим отдельно"

а три слоя не оверинженеринг? есть просто вероятность что твои три слоя достаточно изолированы весьма мала. И есть риск оказаться в ситуации когда у тебя проект это лазанья. Когда изменение на одном уровне требует "прорезать" все слои

контролле принимает запрос, првоеряет права, конвертит джсон в аррэй , разбивает и вызывает серввис с пармаметрами. Сервис делает уже валидацию по бизнесс правилам, создает сущность и вызывает все сеттеры. То есть получается дтакой путь: джсон, аррай, набор параметров для сервиса, куча сеттеров из этих параметров

контролле принимает запрос, првоеряет права, конвертит джсон в аррэй , разбивает и вызывает серввис с пармаметрами. Сервис делает уже валидацию по бизнесс правилам, создает сущность и вызывает все сеттеры. То есть получается дтакой путь: джсон, аррай, набор параметров для сервиса, куча сеттеров из этих параметров

почему бы валидацию не вынести в контроллер?

и валидировать массив

или сразу json

потому что контроллер я вижу как инфраструктурный слой

и на моя взгляд он не должен смотреть н атакое : если, задана время начало, то задать и время конца обязательно

такой себе аргумент)

а валидация входящих данных это прям бизнес логика? бизнес правила, правила валидации у тебя могут лежать в слое предметной области, но валидатор это такая же инфраструктура

далее у тебя бизнес логика должна предотвращать невалидные данные. То есть если с реквестом все хорошо - и дальше все должно быть хорошо. Дальше контроллера смысла юзать валидатор нет.

есть разная валидация. Одно дело проверить что поля не пустые, или что число это число, а не строка

хм

далее у тебя бизнес логика должна предотвращать невалидные данные. То есть если с реквестом все хорошо - и дальше все должно быть хорошо. Дальше контроллера смысла юзать валидатор нет.

то есть в фабрике/билдере/констуркторе вообще проверок не делать?

а поповоду вынести поля как valObject, там типо такие поля - is_hidden, is_deeted, payed_status, timezone, show_in_timetable, show_on_site и т.ж

то есть флаги в оснвоном