я даю платежу ID по сути только там

метод store мне там некуда запихнуть, вот что

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

Т.к. форм реквест тебе уже навязывает определенную структуру

@Enleur проверть вхождение ключевых слов в выдаче?))

Сделал валидацию в функции, 5 строк, за это можно любить laravel

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

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

элис бандл говно

почему?

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

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

не понял

работать с фикстурами как "запихнуть сущность в базу" тоже анриал

тяжело потом поддерживать

потому элис и говно

так я и не хотел в базу пихать

тогда не понял что ты хочешь

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

фэйкер умеет их создавать, но он тут же их флашит

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

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

Никто же не запрещает тебе вынести валидацию в отдельные классы, и сделать реюзабельной. Закинь валидации в middleware, и юзай там например. Получишь некий аналог форм реквестов.

Вот, хотел узнать, куда класть свои вспомогательные классы, так понимаю в middleware?

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

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

излишнее желание "реюзать потом" приводит к сильной связанности да

и слишком сложному коду

или я тебя не так понял?

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

у меня это делается билдерами и фэйкером, ибо иногда надо что-то сильно кастомное

@fes0r так фэйкер записывает в бд

@fes0r так фэйкер записывает в бд

фэйкер не записывает в бд, фэйкер это фэйкер

он тупо генерит рандом

ты можешь им писать в бд а можешь и просто строчку например сгенерить

Вот, хотел узнать, куда класть свои вспомогательные классы, так понимаю в middleware?

Ложи их куда хочешь. Главное неймспейс правильно пропиши

Если middleware, то для них есть отдельная папка в ларавеле

@fes0r https://github.com/fzaninotto/Faker/blob/4e81236d14da84c86f3e96561d689845bcf559ef/src/Faker/ORM/Doctrine/Populator.php#L77

@fes0r https://github.com/fzaninotto/Faker/blob/4e81236d14da84c86f3e96561d689845bcf559ef/src/Faker/ORM/Doctrine/Populator.php#L77

я не польюузсь "популятором"

вот и весь секрет успеха)

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

единообразие

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

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

тогда тесты по кол-ву кода будут превосходить домен))

к тому же не всем сущностям нужны билдеры

*доктриновским, а не доменным

> тогда тесты по кол-ву кода будут превосходить домен)) да не то что бы

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

> и они втыкаются в ентити? гугли шаблон "Builder"

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

Чуваки, которые обсуждали здесь CQRS и прочее. Посоветуйте, какие книжки курить, чтобы разбираться в этом более глубоко? И какие ресурсы читаете? Иногда когда читаю, о чем вы общаетесь, и слабо понимаю, о чем идет речь. Читать по кусочкам статьи, иногда не очень практично, потому что информацию сложно получить всю целостно. Ну и плюс, скоро мне задача предстоит, переписывать самописную систему. Я здесь типа за главного, и какого-то лида спросить совета нет возможности, поэтому хочется по минимуму на грабли попасть.

Чуваки, которые обсуждали здесь CQRS и прочее. Посоветуйте, какие книжки курить, чтобы разбираться в этом более глубоко? И какие ресурсы читаете? Иногда когда читаю, о чем вы общаетесь, и слабо понимаю, о чем идет речь. Читать по кусочкам статьи, иногда не очень практично, потому что информацию сложно получить всю целостно. Ну и плюс, скоро мне задача предстоит, переписывать самописную систему. Я здесь типа за главного, и какого-то лида спросить совета нет возможности, поэтому хочется по минимуму на грабли попасть.

почитай Эванса

> Я здесь типа за главного, и какого-то лида спросить совета нет возможности, поэтому хочется по минимуму на грабли попасть. ну ты можешь тут спрашивать)

но лепить event sourcing или cqrs надо только тогда когда надо

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

и тесты писать)

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

если система существующая - почему было решено ее именно переписывать?

Не так обьяснился. Переписывать, это я её хочу :) А так, её надо будет рефакторить на данном этапе.

Не так обьяснился. Переписывать, это я её хочу :) А так, её надо будет рефакторить на данном этапе.

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

Да я понимаю. Тем более, всё без тестов

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

только не юнит тестов

интеграционные, e2e

хотя бы минимально

Да это все понятно. Мне больше про архитектурные решения, но чуть больше чем просто паттерны

https://gist.github.com/fesor/48677298a04357bb62ac0205f91603ab

можно с этого начать

https://www.youtube.com/watch?v=WpkDN78P884

ERROR: S client not available

можно еще вот это, книжки там мелькали

Хорошо, спасибо

ну а по книжкам

Эванс, Фаулер, "Working efficiency with lagecy code" не помню чья

и главное при всем это KISS и YAGNI

SOLID и GRASP)

?

ну или "изолированный говнокод не говнокод"

@fes0r ладно, убедил

но с популятором было бы проще)

https://github.com/giorgiosironi/eris можно было бы сюда его воткнуть, а так придется велосипедить

@fes0r ладно, убедил

с популятором было бы проще но только для простых случаев

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

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

старина Боб очень быстро и не всегда разборчиво говорит :с

чта?

ну так не делай так как ты описал)

и все будет ок)

короч мое имхо - faker + билдеры = норм.

зато не тратишь время на булшит, мэппинги и прочее

да и генерить все это можно

потом

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

ээээм

ну такое

если бы ты назвал это DbC то норм, а так - это лишняя работа

да и потом

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

наоборот, меньше лишней работы

нарисуй пример в gist

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