Почему?

ну окей окей, если тебя устраивает что и для чтения и для записи используется одна и та же модель - можно назвать это es и что там нет cqrs)

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

Да и смысл то вполне очевидный - мы уже храним ивенты и в будущем можем и проекции начать строить и данные не теряем для них

а тут и нарушение SRP и куча других проблем

но в целом законом не запрещено

а тут и нарушение SRP и куча других проблем

Нарушение надуманных принципов не проблема сама по себе, ну)

SRP надуманный принцип? расплычатый - да, но не надуманный)

Привет, подскажите пожалуйста, а как по уму пробрассывать валидированные входные данные из контроллера в сервис? Десятком параметров? Массивом? DTO? И что должен возвращать контроллер в случае ошибки, не HttpException же?

Ну т.е. будет у тебя поток изменений на вьюхи сильно отличаться от потока изменений на модель - разделишь

Привет, подскажите пожалуйста, а как по уму пробрассывать валидированные входные данные из контроллера в сервис? Десятком параметров? Массивом? DTO? И что должен возвращать контроллер в случае ошибки, не HttpException же?

как тебе удобно (в долгосрочной перспективе), так и делай.

Ну т.е. будет у тебя поток изменений на вьюхи сильно отличаться от потока изменений на модель - разделишь

практика показывать что объединять проще чем разделять)

как тебе удобно (в долгосрочной перспективе), так и делай.

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

практика показывать что объединять проще чем разделять)

Не думаю, что согласен)

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

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

ну это если ты не бложик делаешь конечно

А по поводу передачи, куча параметров не вариант даже визуально - каша, массивы - зло, DTO хороший вариант вроде...

А по поводу передачи, куча параметров не вариант даже визуально - каша, массивы - зло, DTO хороший вариант вроде...

массивы не зло (я так понимаю php), просто нет возможности удобно с типами работать. Что до DTO - если тебе нравится - юзай че

А по поводу передачи, куча параметров не вариант даже визуально - каша, массивы - зло, DTO хороший вариант вроде...

У меня это FormRequest имплементящий интерфейс. там уже getEmail():Email и все такое

У меня это FormRequest имплементящий интерфейс. там уже getEmail():Email и все такое

Лара?

ага.

но вон Фесор вроде и для симфоньки подобное сделал

ага.

Я Lumen использую. Надо будет подумать, чтобы перетащить...

У меня это FormRequest имплементящий интерфейс. там уже getEmail():Email и все такое

А как примерно этот интерфейс называется?

UserCreateRequest

но вон Фесор вроде и для симфоньки подобное сделал

для симфони у тебя есть argument resolver и validator

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

HttpUserCreateRequest extends FormRequest implements UserCreateRequest

HttpUserCreateRequest extends FormRequest implements UserCreateRequest

зачем DTO-хе имплементить интерфейс?

HttpUserCreateRequest extends FormRequest implements UserCreateRequest

? Вник, спасибо!

ну интерфейс принадлежит application layer. а FormRequest - http слою.

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

т.е. это не DTO. а интерфейс с геттерами.

вроде как бы DTO. но не совсем.

хз, если бы были типы я бы массивчики юзал и не парился

@psalm-typedef array{ id: int name: string age: int }

что-нибудь такое

тут как будто struct а не массив

тут как будто struct а не массив

какая разница?) у тебя в php массивы тоже не совсем массивы

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

@psalm-typedef array{ id: int name: string age: int }

ну это ты просто описал коллекцию объектов одного типа )))

ну это ты просто описал коллекцию объектов одного типа )))

нет, коллекция была бы array{array{id: int, ...}}

короч гугли про "php array shapes"

что то по такому запросу ничего не нашлось :( Просто не понятно для чего юзать такие конструкции когда есть объекты

что то по такому запросу ничего не нашлось :( Просто не понятно для чего юзать такие конструкции когда есть объекты

https://docs.hhvm.com/hack/shapes/introduction

что то по такому запросу ничего не нашлось :( Просто не понятно для чего юзать такие конструкции когда есть объекты

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

это самое сильное что есть в php, и без этого php в целом вообще нет смысла рассматривать для разработки. И при этом никто не хочет их юзать... хм... почему? потому что нет возможности статического анализа такой вот херни. Потому все радостно херачат классы (которые тоже не дают всей информации о типах)))) и потом еще мэпперы пишут

но возможность анализа есть - typescript nому доказательство.

просто из анализаторов толковых - вот только недавно psalm появился

https://docs.hhvm.com/hack/shapes/introduction

а в чемпрофит юзать их перед объектами?

по описанию как то сложнее получается

А почему не сделать дто с публичными свойствами? зачем ему вообще геттеры и сеттеры?(без сарказма) - я имею ввиду то, что понятие контракта в пхп сводится просто к использованию интерфейса- в таком случае - если у меня дто не имплементирует интерфейс( и в теории не должен), тогда я просто юзаю паблик филды и не парюсь, так ведь?

я если честно тоже не понимаю. чушь какаято :) видмо хотят как в сишарпе свойство инициализировать в DTO.

а в чемпрофит юзать их перед объектами?

а в чем профит юзать объекты?

а в чем профит юзать объекты?

Find usages?

а в чем профит юзать объекты?

хотя бы более наглядно получется, сравнивая с докой выше

+ поведение можно задать

А почему не сделать дто с публичными свойствами? зачем ему вообще геттеры и сеттеры?(без сарказма) - я имею ввиду то, что понятие контракта в пхп сводится просто к использованию интерфейса- в таком случае - если у меня дто не имплементирует интерфейс( и в теории не должен), тогда я просто юзаю паблик филды и не парюсь, так ведь?

так никто и не мешает

так никто и не мешает

вот именно, но все упорно лепят интерфейсы в дто и фигачят геттеры/сеттеры- вопрос, в чем профит?

вот именно, но все упорно лепят интерфейсы в дто и фигачят геттеры/сеттеры- вопрос, в чем профит?

если ты о посте выше, то там не dto

Find usages?

а тебе это часто надо для DTO?

если ты о посте выше, то там не dto

я в общем

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

нужна структура данных - делай структуру данных

я в общем

в общем - я не знаю зачем там интерфейс :) dto сам себе интерфейс )))

в общем - я не знаю зачем там интерфейс :) dto сам себе интерфейс )))

что такое интерфейс?)

?

в данном контексте - это значит что объект содержит консистентные данные

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

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

что такое поведение?

$dto->getName(); - это не поведение?

$dto->getName(); - это не поведение?

тогда и $someRepository->getById() - тоже не поведение :)

$dto->getName(); - это не поведение?

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

особенно если потом ты запихнешь это дело в условие какое

для DTO ?

для DTO ?

в DTO нет поведения. никакого. достать поле это не поведение

с тем же успехом можно делать просто поля, но тут начинают ныть "но тогда не имутабельно" и начинается херня с геттерами в связи с отсутствием final в php

в DTO нет поведения. никакого. достать поле это не поведение

ты же не знаешь что там внутри :)

ты же не знаешь что там внутри :)

если это DTO и я не знаю что там внутри - это не DTO

$dto->name - это не поведение, хотя ...

и если это не DTO и там есть getName то 90% что я буду злиться

после того как пройдусь по findUsage

а вот кто DTO делает. вы их как называете? UserCreateDTO есть такой суффикс? я в паре проектов видел.. и мне чтото не нравится

я не делаю

и если это не DTO и там есть getName то 90% что я буду злиться

Открываешь %name%DTO, а там бизнес логика ?

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

а как называешь?

Открываешь %name%DTO, а там бизнес логика ?

ну там может быть что то типа getName(){return toLower $name} но бизнес логику туда сложновато запихнуть...

ну там может быть что то типа getName(){return toLower $name} но бизнес логику туда сложновато запихнуть...

Пхп не удобен в этом плане :(

а вот кто DTO делает. вы их как называете? UserCreateDTO есть такой суффикс? я в паре проектов видел.. и мне чтото не нравится

мне сама концепция dto не нравится, а так у меня они с суффиксами (как бы я их не любил)

ну там может быть что то типа getName(){return toLower $name} но бизнес логику туда сложновато запихнуть...

это уже не dto, а какой-то презентер, вью модель или чего еще

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

это уже не dto, а какой-то презентер, вью модель или чего еще

а почему нет, дто принимает данные, валидирует, и отдает такие какие они нужны приложению

а почему нет, дто принимает данные, валидирует, и отдает такие какие они нужны приложению

dto не валидирует данные, этим занимается валидатор внешний. иначе это VO. следует разделять эти понятия

dto не валидирует данные, этим занимается валидатор внешний. иначе это VO. следует разделять эти понятия

в таком случае dto вообще лишняя прослойка

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

в таком случае dto вообще лишняя прослойка

вся соль dto - структура данных. И используют для этого классы в основном потому.... что языки эти не предусматривают альтернативы) в c# вон есть struct

они и в C и в C++ есть. Более того, классы по сути и есть struct

кстати я забыл уже чем в шарпе стракты от класов отличаются.