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

Т.е. на каждый запрос - отдельный класс

Вроде как

Ой, сколько у меня тавтологии...

Да скорее всего как-нибудь и называется типа Action Class.

Не, там именно философия какая-то

Ну, то есть с Платоном и афинянами?

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

А не сам класс

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

Документация же, не? https://symfony.com/doc/current/doctrine/multiple_entity_managers.html

пропустил этот раздел :( спасибо

Ну, если что, гугл спасает. Я туда написал "Symfony Doctrine multiple databases" и оно на первой строчке было :)

Опыт показывает, что если начать гуглить на английском, релевентность результатов вырастает в разы.

Как думаете? есть ли смысл морочиться с разными методами в репозитории для разных степеней "заполненности" объекта?) Все тот же пример из моего блога, с авторами, их постами и заметками. В репозитории автора у меня есть метод getQuery, который собирает запрос с двумя джоинами, репозиторий авторов использует этот запрос для получения списка авторов и на выходе у меня сразу авторы с постами и заметками, без всяких ленивых загрузок. Но, наверно, мне не всегда будут нужны и посты и заметки. Это вообще проблема или я перезаморочился?)

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

Я тоже делаю так, как сказал комрад выше.

Вроде нормально выглядит (на мой вкус и моё ИМХО).

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

ну т.е. в репозитории методы типа getAuthorsWithComments getAuthorsWithNotes ...WithNotesAndComments

Да, наверное. Только тут надо аккуратнее с семантикой. В том числе помнить, что такое find, а что такое get. Ну и в целом да, получатся методы с разной степенью гидрации, но главное, как мне кажется, отталкиваться не от проблематики, а не от того, что "просто хочу несколько методов чтобы по-разному коллекции наполняли".

Да, наверное. Только тут надо аккуратнее с семантикой. В том числе помнить, что такое find, а что такое get. Ну и в целом да, получатся методы с разной степенью гидрации, но главное, как мне кажется, отталкиваться не от проблематики, а не от того, что "просто хочу несколько методов чтобы по-разному коллекции наполняли".

спасибо)

Кстати, по поводу работы с сущностями, доктрины и всего такого, у Окрамиуса есть хороший доклад, который я бы мог советовать послушать. https://www.youtube.com/watch?v=rzGeNYC3oz0 Его тут, скорее всего, уже кидали, но он от этого хуже не становится :)

ну т.е. в репозитории методы типа getAuthorsWithComments getAuthorsWithNotes ...WithNotesAndComments

А я бы называл от того, для чего это используется, используя смысловое наполнение того, где это используется.

Я, в общем-то о таком и говорил. О контексте. Хотя местами у меня тоже бывает getPostWithComments() когда это наиболее логично звучит в данной ситуации.

А я бы называл от того, для чего это используется, используя смысловое наполнение того, где это используется.

ну да, как вариант, действуем по ситуации. Понял, спасибо Всем)

Кто нибудь пользовался LexikFormFilterBundle?

А я бы называл от того, для чего это используется, используя смысловое наполнение того, где это используется.

таким методам не место в репозитории

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

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

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

которые не умеют persist и которые делают тупые read-only выборки

и тогда жизнь будет чуть меньшей болью

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

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

ааа кажись понял

но лучше будет если пояснишь))

У меня получилось как то так AuthorRepository +getAuthorsWithPostsQuery():qb +getAuthorsQuery():qb AuthorManager +getAuthorsWithPosts():Author[] +createAuthor():Author +update($author) // тут работаем с базой

все как на той картинке

блин, надо себе футболку с таким принтом заказать

но лучше будет если пояснишь))

Поясняю. Тебе этот список нужен в рамках бизнес логики или на UI показать?

Поясняю. Тебе этот список нужен в рамках бизнес логики или на UI показать?

показать

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

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

тогда и пачки геттеров из сущностей уйдут

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

воимя SRP

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

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

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

если у тебя какие-то правила выборки есть определенные - формируешь объект-критерию для коллекции.

спасибо, подумаю над этим

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

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

если кто может накинуть таких буду рад

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

когда-нибудь я тоже научусь так говорить

когда-нибудь я тоже научусь так говорить

я думал я один плохо понял Сергея

гм

"плохо" подразумевает "хоть как-то"

явно не мой случай

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

Странно, чатик на мобилке не подгружается.

вот где-где, а на пикабу я такого точно не ожидал)) http://pikabu.ru/story/doctrine_best_practices__1_4327349

таким методам не место в репозитории

Вероятно, я на SF не пишу уже достаточно долго, могу говорить ерунду :)

вот где-где, а на пикабу я такого точно не ожидал)) http://pikabu.ru/story/doctrine_best_practices__1_4327349

Это краткая выжимка того доклада, что я выше кидал. Причём, менее понятная, чем сам доклад.

ну да, то что было на видео

ERROR: S client not available

просто место размещение неожиданное:)

чуваки

Это да.

а поясните мне за композер

вот у меня в проекте мы коммитим vendor в репу, прям всю папку в гит

зря наверное)

вот у меня в проекте мы коммитим vendor в репу, прям всю папку в гит

Супер.

я так понимаю, что это неправильно

но

правильно понимаешь)

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

Коммитить надо composer.json и composer.lock.

ну локально ж вендор есть

где локально?

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

Можете держать свой сервер-прокси для packagist. Есть как Standalone так и saas.

Можете держать свой сервер-прокси для packagist. Есть как Standalone так и saas.

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

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

da horsie, Нельзя ругаться! [Предупреждений 4/5]

где локально?

на машинах, на которых ведется разработка

на машинах, на которых ведется разработка

хорошо, а как быть с дженкинсами и продом?

и стейджем

и остальными

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

меня будут иметь всем отделом

потому что я сломал CI

своим предложением

Поднимите satis.

https://code.tutsplus.com/tutorials/setting-up-a-local-mirror-for-composer-packages-with-satis--net-36726

Поднимите satis.

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

Ну впихни его к дженкинсу.

я думал я один плохо понял Сергея

погугли "Entity Aggregate"

все тот же вопрос

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