Спасибо за ответ. Если дто делается из массива, то метод его создания кладется рядом, да если в другом месте будет точно такой же массив - будет неудобно) Но часто у Вас встречается fromArray из двух разных мест? у меня - никогда (тут стоит уточнить что дто я создаю относительно часто вот только для этого всегда лучше подходит конструктор, а чтобы применить fromArray массив должен быть прям один в один), хотя это может сильно зависеть от проекта... Использовать же fromFile т.е. делать парсинг файла внутри дто (я правильно понял?) мне не позволит совесть (по мне это нарушение srp)
На самом деле если порезать Services на методы, то получатся Actions, а если порезать Repositories на методы получатся Queries. Action (пишет в базу) может вызывать другие Actions и Queries для выполнения своей бизнес задачи. Query (читает из базы) может вызывать только другие Query, Поскольку action может вызывать другой action может возникнуть кольцевая зависимость с чем и борется создатель упомянутого Porto. Но на практике на мелких проектах это должно ловится на деве и тестах и усложнять описанную схему я не хочу, Проблема в моём подходе пока одна - слишком много мелких классов т..к на getById нужен отдельный класс и мне придется объединять их в папки, которые по сути и будут репозиториеми, а папок и так уже много с учетом модулей, дто и прочего.
Кстати, всегда было интересно, почему все делают вот так
UserDTO::fromRequest($request)
вместо того чтобы делать вот так
$request->getUserDto()
ведь реквест уже содержит все данные и валидацию для них, а получение из него DTO уникально и больше нигде кроме места с реквестом не пригодится, так почему метод формирования у находится в DTO?
Согласен с Вами, моё личное мнение, что весь важный бизнес код должен быть внутри useCase'а , поэтому письмо еще можно вынести в события, но передачу в службу доставки - нет. Иначе получится лазанья код из разбросанной по приложению важной логики, которую устанешь собирать. Составление карты "этого", вместо того чтобы так не делать, больше похоже на способ создать себе сложности, а потом героически их преодолевать.
Если Вы сомневаетесь нужен ли Вам фреймворк, то он Вам точно нужен, т.к. у Вас не хватает экспертизы в вопросе, иначе бы сомнений не было. Даже если Вы уверены что фреймворк не нужен это может быть ошибкой. На мой взгляд этим вопросом чаще всего задаются новички, для них ответ однозначный: «нужен» и нет это не означает что нужно «программировать на фреймворке» т.е. изучать только фреймворк, и не изучать возможности языка программирования. Попробовать написать свой фреймворк полезно, начинаешь понимать почему те или иные решение были взяты в известных фреймворках, но делать такие эксперименты нужно на «второстепенных» проектах, которые переписать или выкинуть не составит большого труда.
На локальной машине нормально работает, в инетах полно видео (wsl 2 vcxsrv), не натив конечно, но и секунды ждать не приходится. Проверял на Firefox, PHPstorm. В конце года обещают поддержку из коробки для запуска gui из wsl, возможно будет еще лучше.
Если использовать git внутри wsl, то PhpStorm не подсвечивает строки с изменениями (это логично), если использовать git в Windows, то в какой-то момент перестают трекаться изменения, в диалоге коммита нужно нажимать «обновить», сделайте хоть чтобы «обновить» вызывалось автоматически при открытии диалога коммита (это ведь ничего не поломает), а то так можно «удачно» пропустить важные файлы. (проект лежит в папке пользователя в wsl)
Спасибо за ответ. Если дто делается из массива, то метод его создания кладется рядом, да если в другом месте будет точно такой же массив - будет неудобно) Но часто у Вас встречается fromArray из двух разных мест? у меня - никогда (тут стоит уточнить что дто я создаю относительно часто вот только для этого всегда лучше подходит конструктор, а чтобы применить fromArray массив должен быть прям один в один), хотя это может сильно зависеть от проекта... Использовать же fromFile т.е. делать парсинг файла внутри дто (я правильно понял?) мне не позволит совесть (по мне это нарушение srp)
На самом деле если порезать Services на методы, то получатся Actions, а если порезать Repositories на методы получатся Queries. Action (пишет в базу) может вызывать другие Actions и Queries для выполнения своей бизнес задачи. Query (читает из базы) может вызывать только другие Query, Поскольку action может вызывать другой action может возникнуть кольцевая зависимость с чем и борется создатель упомянутого Porto. Но на практике на мелких проектах это должно ловится на деве и тестах и усложнять описанную схему я не хочу, Проблема в моём подходе пока одна - слишком много мелких классов т..к на getById нужен отдельный класс и мне придется объединять их в папки, которые по сути и будут репозиториеми, а папок и так уже много с учетом модулей, дто и прочего.
Кстати, всегда было интересно, почему все делают вот так
UserDTO::fromRequest($request)
вместо того чтобы делать вот так
$request->getUserDto()
ведь реквест уже содержит все данные и валидацию для них, а получение из него DTO уникально и больше нигде кроме места с реквестом не пригодится, так почему метод формирования у находится в DTO?
Согласен с Вами, моё личное мнение, что весь важный бизнес код должен быть внутри useCase'а , поэтому письмо еще можно вынести в события, но передачу в службу доставки - нет. Иначе получится лазанья код из разбросанной по приложению важной логики, которую устанешь собирать. Составление карты "этого", вместо того чтобы так не делать, больше похоже на способ создать себе сложности, а потом героически их преодолевать.
DNK-H