Тема: Получить количество статей каждого пользователя

Здравствуйте, очень простая задача, но не знаю как это правильно реализовать в доктрине

У меня есть 2 сущность User и Article связь один ко многим .
Нужно вывести всех(10-20 ) пользователей и количество статей каждого пользователя.

есть совсем неправильный вариант получить требуемых пользователей и в цикле (User->getArticles()->count())плодить дополнительные  запросы к бд
а такого не нужно.
как сделать это правильно ?

2

Re: Получить количество статей каждого пользователя

DQL http://docs.doctrine-project.org/projec … t-examples

3

Re: Получить количество статей каждого пользователя

$qb = $this->createQueryBuilder('u')
            ->select("u, count(a) AS articles_count")
        ->join('u.articles', 'a')
            ->addGroupBy('u.id');
 
        $query = $qb->getQuery();
 
        return $query->getResult();

этот код выводит articles_count отдельно от объекта User а мне нужно внутри пробовал добавлять в User поле с таким же названием но всё равно не подействовало

4

Re: Получить количество статей каждого пользователя

Естественно отдельно, оно не является частью сущности User. Внутри, это самому поддерживать аггрегатное свойство. http://docs.doctrine-project.org/projec … ields.html

Ну может еще какими-нибудь костылями через события доктрины

5

Re: Получить количество статей каждого пользователя

shurastik пишет:

Ну может еще какими-нибудь костылями через события доктрины

Лучший способ отстрелить себе ногу, а потом испугаться и снести полбашки.

Ссылка в документацию на агрегатные свойства исчерпывающе отвечает на вопрос.

6

Re: Получить количество статей каждого пользователя

Да-да, абсолютно согласен )) http://ocramius.github.io/doctrine-best-practices/#/59

Re: Получить количество статей каждого пользователя

В рамках топика event-ы doctrine вовсе не нужны, т.к. вам совсем не то нужно, для чего они придуманы. У вас дальше репозитория и уходить не нужно.

А чем конкретно плохи event-ы? У нас в системе достаточно много слушается разных событий, как от doctrine, как от symfony, как своих кастомных, как из vendor-ных bundle-ов, да чет проблем не заметил с этим. Особенно, после NodeJS и событийно-ориентированного подхода к системе. Причем у нас есть свои bundle-ы, которые кочуют между проектами и разные проекты тоже слушают события default/smile

8

Re: Получить количество статей каждого пользователя

daemon_master пишет:

В рамках топика event-ы doctrine вовсе не нужны

Не нужны, но сделать же на них можно. ^__^

daemon_master пишет:

А чем конкретно плохи event-ы?

Ивенты сами по себе ничем не плохи. Плохо, когда их много. И особенно плохо, когда они участвуют в бизнес-логике.
Плохо потому, что они неочевидны. В коде, который отвечает за какое-то бизнес-действие, нет ничего про то, что где-то в каких-то дебрях кода какой-то слушатель перехватывает генерируемое этим кодом событие и что-то меняет в его результате, например. Это чистый хак.

В небольших проектах это не проблема, но когда кода и бизнес-логики много — с активным использованием событий вы намного раньше достигнете Ада. Слушатели идеально подходят для каких-то рутинных фоновых операций, которые не вмешиваются в бизнес-логику.

Re: Получить количество статей каждого пользователя

Усложнить бизнес-логику можно и не только ивентами, но и кучей сервисов, в которых очень легко запутаться, когда их уйма. Другими словами, в сложной бизнес-логике сложно default/smile Если увезти взгляд в сторону архитектуры, есть такая штука, которая называется Domain Events [один из разделов DDD], который и строит общение между доменами в рамках событий.

В итоге, если все хорошо с документацией, с тестами и на проекте есть человек, который делает а-та-та-та за то, что ломаешь идею проекта/бандла/сервиса/etc., проблем не должно возникнуть ни с событийной моделью, ни с какой другой default/smile

P.S. тема просто на похоливарить и уже мало относится к топику default/smile

10

Re: Получить количество статей каждого пользователя

daemon_master пишет:

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

Подскажите, где находится эта идеальная вселенная? default/smile

Я всегда исхожу из того, что:
1. Код должен быть максимально самодокументируемым. Потому что полагаться на адекватность и актуальность документации нельзя;
2. Тестам доверять нельзя. Они нужны и полезны, но ни разу не панацея и их эффективность зависит от качеств и квалификации программиста. Тест может не покрывать проблему, потому что программист, писавший тест, не догадывался о том, что данная проблема может существовать. Хорошо, когда тесты и код, который они покрывают, пишут разные люди;

Именно с самодокументируемостью у событий все плохо. default/smile
А так конечно при должном старании можно независимо от способа сделать из проекта помойку. Просто с событиями это проще и быстрее.

11

Re: Получить количество статей каждого пользователя

relo_san пишет:

Подскажите, где находится эта идеальная вселенная?

взгрустнул default/sad

daemon_master пишет:

Domain Events

И они используются в основном для интеграции разных Aggregate Root-ов и Bounded Context-ов, чтобы ослабить связи.

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

А события... Итеграция в сторонние библиотеки/фреймворки, куда уж без этого. Иногда и вариантов-то других нет (тот же HttpKernel).

В общем, имхо, для инфраструктурного слоя - да, для домена - скорее нет

12

Re: Получить количество статей каждого пользователя

relo_san пишет:

Подскажите, где находится эта идеальная вселенная?

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

По поводу тестов, могу привести пример как у нас.
Разработчики пишут Unit-тесты. По ним выработаны правила, что и как покрывать. В код ревью смотрится не только код, но и тесты к нему. И, поначалу, если новый человек на проекте, то непривычно с той стороны, что есть замечания и к тестам. Ну и тесты запускаются на каждый Pull Request в репозиторий, а-ля CI.
И еще у нас есть тестировщики, которые пишут свои авто-тесты. Они покрывают уже поведение пользователя. API, Admin-ку и т.д. Т.е. если ты накосячишь в каких-то тестах, то это быстро всплывет.
Какие плюсы это нам даёт (дабы не просто писали тесты ради тестов):
1.  при обновлении какой-нибудь сторонней либы (в том числе и переход между версиями Symfony [сейчас на 2.7, а начинали проект еще с 2.4]), быстро всплывают зависимости ее использования;
2. при рефакторинге какого-нибудь отдельного компонента. По тестам сразу же находим, где он использовался;
3. фикс мелких багов прямо при написании тестов, не часто, но такое случается, что при написании теста, понимаешь, что что-то не учел в коде.

shurastik пишет:

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

По сути, слушатель события тоже сервис. Через команду

app/console debug:event-dispatcher

ты увидишь, что подписано на конкретный event, за исключением слушателей, которые вешаются в момент выполнения кода, и доктриновских. С тем, что зависимости сервиса посмотреть проще, тут не спорю.

*P.S.* благодарю за ответы на этот вброс default/smile

13

Re: Получить количество статей каждого пользователя

Так и никто и не спорит, что тесты - это прекрасно default/smile

Просто помимо удачи разрабатывать проект с нуля, с компетентными коллегами, можно получить тонну legacy-говнокода, где хорошо если повезет, что код вообще тестируемый. И приходиться постоянно бодаться с бизнесом, чтобы выбить ресурсы и хоть немного приблизиться к этой самой "вселенной" default/smile

14

Re: Получить количество статей каждого пользователя

А какая бизнесу разница, есть у вас тесты в коде или нет? Нашему бизнесу все равно, мы это для себя пишем, а не для бизнеса.
По поводу легаси - тут боль. Приходилось работать с тем, где Copy-Paste detector показывал 30% на ~300к строк проекта. Если меняешь в одном месте, то потом замени еще в 15-ти. И это наследие досталось от индусов. Глаз дёргается, когда вспоминаю

15

Re: Получить количество статей каждого пользователя

daemon_master пишет:

А какая бизнесу разница, есть у вас тесты в коде или нет?

Не все так однозначно. © default/smile

Если все и так работает, то бизнесу никакой разницы нет, и правда. Ибо, «зачем платить больше»™.
Но бизнесы и проекты бывают разные. Если для бизнеса критична надежность и безопасность приложения (типично для ecommerce, например), а тесты дают определенный процент к этой самой надежности и безопасности, то бизнесу уже есть разница. Бизнес стремится к минимизации расходов и повышению эффективности. Если расходы на написание и поддержку тестов ниже, чем вероятные имиджевые/финансовые потери из-за факапа — бизнес будет за тесты.
Сюда же относится стоимость поддержки активно разрабатываемых проектов, она сильно зависит от наличия тестов и ценник на разработку новой фичи на проекте без тестов может весьма существенно отличаться от ценника на такую же фичу на проекте, где тесты есть. В общем, нормальный бизнес всегда прагматично все считает.

16

Re: Получить количество статей каждого пользователя

Ок, смотри, я хотел другую мысль донести. Как бизнес может запрещать писать тесты? Часто приходится слышать, что менеджеры не дают нам время на тесты. И вот тут возникает вопрос: а чего вы вообще у них про это спрашиваете?

17

Re: Получить количество статей каждого пользователя

daemon_master пишет:

Как бизнес может запрещать писать тесты? Часто приходится слышать, что менеджеры не дают нам время на тесты. И вот тут возникает вопрос: а чего вы вообще у них про это спрашиваете?

Есть разные подходы в договоренностях с клиентами и в работе. Разумеется, можно впилить тесты раз и навсегда в цикл разработки и ставить клиента перед фактом, что если он хочет сэкономить на тестах, то пусть идет в другую компанию. Нивапрос.

Вы же тесты пишете в рабочее время, оплачиваемое клиентом. И в смете, предоставляемой клиенту, обычно пишете «разработка спецификации — столько-то часов, разработка приложения — столько-то часов, тесты — столько-то часов». И клиент за все это платит. У него есть все основания поинтересоваться, что означает пункт «тесты», зачем он и насколько обязателен. Или например он может сходу заявить, что тесты ему неинтересны, он стеснен в средствах и оплачивать их не будет. Просто потеряете клиента? Или будете писать тесты за свой собственный счет/в нерабочее время? default/smile

18

Re: Получить количество статей каждого пользователя

У нас сейчас еще и отличие в том, что сейчас я работаю в продуктовой компании. Так и написание тестов не входит разве в процесс разработки? Как по мне, это тоже самое, что и дебаг. В отдельный же пункт не пишется - дебажил код. Это ИМХО и может отличаться default/wink

19

Re: Получить количество статей каждого пользователя

daemon_master пишет:

Так и написание тестов не входит разве в процесс разработки?

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

Клиент делает заказ и платит деньги, ему этим приложением потом владеть. Он имеет право решать, что ему надо а что нет. Вне зависимости от, конечное решение за ним, и если он просчитается — это его просчет и его бизнес.
Да, как я уже выше написал, можно просто поставить обязательное условие на написание тестов и если клиента этот пункт не устраивает — отправлять его лесом. Некоторые компании так и делают, и имеют на это право и свои причины (имиджевые, например).

Опять же, проекты бывают очень разными, и все под одну гребенку стричь также некорректно. Если проект изначально не рассчитан на долгую активную фазу разработки и его предполагается реализовать силами одного программиста в пределах 1-3 месяцев, то ему тесты в принципе не особо нужны. Да, не помешают, но если клиент не готов за них платить — проекту от этого существенно хуже не станет. Один программист в пределах 3 месяцев активной работы над одним проектом вполне сам помнит зависимости и что где используется. Плюс, в конце так или иначе придется оттестировать работу проекта ручками перед передачей заказчику, чтобы убедиться, что все нормально и выглядит и работает так, как задумано. Косяки там всплывут. А если проект большой и его предполагается пилить силами 5-10 программистов пару лет, то ценник «без тестов» для него просто будет выше, чем с тестами, по объективным причинам, поэтому клиенту будет невыгодно отказываться от тестов.