это просто данные, это не инварианты твоих моделей

а как обычно данные присылают сервису (ну, я так называю то, что вызывает контроллер)? Вот пришёл реквест в контроллер, дальше в контроллере создаётся какой-то простой объект с набором данных и отправляется сервису? По идее это было бы удобно, особенно когда куча параметров приходит, потому-что иначе список параметров метода сервиса будет километровым

а как обычно данные присылают сервису (ну, я так называю то, что вызывает контроллер)? Вот пришёл реквест в контроллер, дальше в контроллере создаётся какой-то простой объект с набором данных и отправляется сервису? По идее это было бы удобно, особенно когда куча параметров приходит, потому-что иначе список параметров метода сервиса будет километровым

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

сущности не валидируются кроме как по типам в конструкторе\мутаторах

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

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

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

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

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

но что тогда, если у нас 2 способа ввода информации: 1. Вэб морда 2. Пользователи скидываю xml на фтп и нам надо засосать всё это дело. Конечно во втором случае валидация тоже нужна, а процесс её вызова получается завязан на контроллер

но что тогда, если у нас 2 способа ввода информации: 1. Вэб морда 2. Пользователи скидываю xml на фтп и нам надо засосать всё это дело. Конечно во втором случае валидация тоже нужна, а процесс её вызова получается завязан на контроллер

ну я отношусь к валидатору как к сервису в каком-то роде. информация о том, как валидировать, лежит либо в нём, если он заточен под объект, либо как-то привязана к объекту, если валидатор обобщенный (как в симфони, например). ты можешь вызвать его в контроллере и собрать из ошибок нужный тебе вью (html, json, xml, whatever). можешь вызвать его в команде, которая разбирает xml, получить тот же набор ошибок, но поступить с ними уже иначе, на почту там отправить ошибку или тупо залогировать или что ты там хочешь. т.е. дублируется между контроллером и командой только строчка $this->validator->validate(), не вижу в этом ничего страшного.

но что тогда, если у нас 2 способа ввода информации: 1. Вэб морда 2. Пользователи скидываю xml на фтп и нам надо засосать всё это дело. Конечно во втором случае валидация тоже нужна, а процесс её вызова получается завязан на контроллер

UI - > DTO -> application

UI - > DTO -> application

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

> в какой момент валидировать. между UI и приложением

у тебя эта штука называется контроллер

у меня - адаптер)

XML файл - это про batch процессинг который в целом может быть разбит просто на список DTO которые закидываются по одной

ну я отношусь к валидатору как к сервису в каком-то роде. информация о том, как валидировать, лежит либо в нём, если он заточен под объект, либо как-то привязана к объекту, если валидатор обобщенный (как в симфони, например). ты можешь вызвать его в контроллере и собрать из ошибок нужный тебе вью (html, json, xml, whatever). можешь вызвать его в команде, которая разбирает xml, получить тот же набор ошибок, но поступить с ними уже иначе, на почту там отправить ошибку или тупо залогировать или что ты там хочешь. т.е. дублируется между контроллером и командой только строчка $this->validator->validate(), не вижу в этом ничего страшного.

У меня просто была мысль сделать объект Result, который бы содержал в себе ошибки и результат выполнения операции. Хотя там всё равно надо было бы вызывать метод проверки есть ли ошибки...

У меня просто была мысль сделать объект Result, который бы содержал в себе ошибки и результат выполнения операции. Хотя там всё равно надо было бы вызывать метод проверки есть ли ошибки...

о том и речь. обобщение в один объект всё равно не спасёт тебя от ифов. даже если ты напишешь хитрую сериализацию, которая сама решит что надо выдать юзеру, тебе как минимум нужно будет что-то в духе $statusCode = $result->isError() ? 400 : 200 чем меньше вариантов отдает метод, тем меньше тебе надо проверять что же он вернул. и запаковка в один объект не решает проблему, по факту ты просто общий тип изобрёл. только вот использовать его в общем виде ты не можешь.

у меня - адаптер)

вот кстати недавно меня начал занимать вопрос, чем является контроллер? У меня такое ощущение сложилось, что это преобразователь данных для способа ввода через вэб. То есть ответственность контроллера - преобразовать данные из реквеста в форму понятную приложению. Я так понимаю, что приведение типов тоже входит в обязанность контроллера. Ну например приходит поле datetime в виде строки, а контроллер из него должен сделать DateTime объект например

1. мэпим данные на DTO 2. валидируем DTO (можно декоратором над приложением, тут люди любят упарываться во всякие command bus 3. если валидация не прошла - можно или кинуть исключение или реально вернуть какой-то объект где будет поле errors непустое (привет го)

вот кстати недавно меня начал занимать вопрос, чем является контроллер? У меня такое ощущение сложилось, что это преобразователь данных для способа ввода через вэб. То есть ответственность контроллера - преобразовать данные из реквеста в форму понятную приложению. Я так понимаю, что приведение типов тоже входит в обязанность контроллера. Ну например приходит поле datetime в виде строки, а контроллер из него должен сделать DateTime объект например

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

вообще можешь погуглить GRASP controller

контроллер в контексте http приложения это просто адаптер http <-> application. Соответственно для CLI приложения у нас свой адаптер а для xml batch processing свой

Привет, подскажите пожалуйста канал в котором выкладывают книги по программированию.

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

Привет, подскажите пожалуйста канал в котором выкладывают книги по программированию.

а какие книги интересуют?

а какие книги интересуют?

по веб разработке

все книги по веб разработке - мусор)

годится только для растопки печи)

ты хоть одну прочитал?

нет конечно

ну вот, смотри дальше ютуб

по веб разработке

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

какие дерзкие джуны-то нынче пошли...

ну вот, смотри дальше ютуб

ютуб полезнее книг по разработке будет

Привет, подскажите пожалуйста канал в котором выкладывают книги по программированию.

Страуструп теория программирования на с Кнут теория алгоритмов Александреску ооп и с Дейт введение в бд

Страуструп теория программирования на с Кнут теория алгоритмов Александреску ооп и с Дейт введение в бд

это не книги по веб разработке, так-то)

это смотря с какой стороны посмотреть ))

ему надо чёт вроде свой блог за 21 день)

это смотря с какой стороны посмотреть ))

ну, с какой не посмотри)

боюсь если человек ищет книги по вэб программированию - это даже не джун, а совсем начинающий =\ Это вот я джун (и то только потому, что это php :D )

В книгах как раз очень много полезной инфы.

в нигах по веб разработке полезной инфы нет)

но ты пока не в состоянии понять о чём речь)

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

И что посоветуете для изучения? Только документацию?

Она всегда актуальна)

посоветуем учить не веб-разработку, а программирование и инфраструктуру

И что посоветуете для изучения? Только документацию?

изучать надо программирование) концептуальные подходы. А не смотреть как копипастить jquery в сайт, что бы окошечки всплывали.

Есть примеры, сайты, книги, каналы?

ну тебе там выше накинули. Этого на пол года хватит)

ого, рекомендую Александреску для начала, неплохо так

я б посоветовал в качестве базы почитать SICP

Спасибо.

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

я на freecodecamp

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

зандстра для начала это как то мощновато

Котеров?

ну перед зандастрой синтаксис на пхп.нете почитать и ок)

ну вот оч хорошо заходит связка Котеров \Зандстра

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

поддерживаю, это первая книга, которую я прочитал по PHP. Правда совсем элементарные вещи я тогда уже какие-то знал. Для нубаса - самое оно

Именно во время чтения этой книжки я понял, что такое композиция и это взорвало мне мозг :D

чёт не припомню, что бы зандастра там нормально за композицию вещал)

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

Для начала можно взять любую книгу по веб разработке. Там можно потчерпнуть знания из серии "как подключть jQuery", "обработать форму", "отправить мыло". После прочтения можно двигаться в ту сторону куда ентереснее. Собственно во фронт или в бэк. Ну а выбрав направление можно уже и соответсвующую литературу смотреть. Тут уже много накидали вариантов. Мы джунам (вот прям с нулевыми знаниям) даем ссылки на доки и мелкие таски. Если человек тяготеет к беку, то двигаем в этом направлении, если к фронту, то в соответсвующем. ИМХО, для начала нужно определиться зачем оно нужно это самое программирование и к чему есть способности)

"Там можно потчерпнуть знания из серии "как подключть jQuery", "обработать форму"," та нахуя?)

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

ERROR: S client not available

и что он легче усваивает

талант к подключению jquery?)

для некоторых это сложно)

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

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

а почему в пхп это долно быть плохо?

слышал от кого-то в чате об этом

мой кейс - обработка ивентов есть мидлвара, ловящая их, есть два гейтвея (синхронный и асинхронный диспетчеры)

сейчас юзается is_subclass_of (ну почти instanceof)

ну стратегия в помощь. а там в supports будет снова запрятан instanceof

так-то ничего плохого нету. Ну прям совсем)

вопрос в другом. Почему у тебя событие знает какое оно (синхронное или асинхронное)

мб у тебя там события - вовсе не события?) а события и хуки?)

ну фактически асинхронных сейчас нет это так, замашка на будущее (вижу место для этого в ближайших фичах) события - в рамках tactician все как обычно: команда потриггерила события, потом хендлеры событий и так далее

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

ну я ничего плохого в instanceof не вижу) моб Сергей чёт накинет, но как по мне - норм) меня ток идея с разными "типами" событий смущает)

давай холиварить

хотя

лень)

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

я ж любитель обмазаться басами) у меня нет синхронных событий)

ну я ничего плохого в instanceof не вижу) моб Сергей чёт накинет, но как по мне - норм) меня ток идея с разными "типами" событий смущает)

зависит от того для чего. Если для того что бы вот мне приходят подтипы и иногда там надо чуть по другому - ты положил большой болт на учения бабушки Лисков и на полиморфизм. Если тебе норм - ну ок.

но в php иногда других вариантов нет....

ну вот как раз случай с событиями, о которых выше говорил. мну смущает

для того что бы роутить ивенты я лично ничего плохого в instanceof не вижу

ну вот вся аргументацию, что я нашел - "если у вас instanceof, кладите логику в класс"

хотя опять же мне кажется это несколько странным

типа class-specific логика должна относиться к нему

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

смущает потому, что событие несёт в себе данные о том, как будет обрабатываться

хотя опять же мне кажется это несколько странным

ну вот я второй вариант набросил, сейчас он выглядит логичнее > ну другой вариант, который вижу - все события синхронны, а где надо - уже кладем в кролика аль куда мессагу

смущает потому, что событие несёт в себе данные о том, как будет обрабатываться

оно не несет - это решает контекст на основе instanceof. просто в этом случае у тебя контекст знает слишком много

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