Слушайте, ну конкатенация строк тоже высокоуровневая абстракция. Не байты же мы объединяем. QueryBuilder достаточно низкий уровень. И если у вас сервис занимается составлением QueryBuilder и потом отправляет его в репозиторий, то это означает что слой с сервисом лишний. Пример isVip и 2 статуса не совсем корректный. И isVip и статусы это бизнес-свойства. Status.Platinum вполне себе бизнес-часть. Вот если если bool isVip, а в таблице tiny int is_vip, то пример был бы удачнее.
Но в любом случае формирование QueryBuilder в отдельном сервисе лично мне не нравится. Но вы делайте как вам удобно. Главное, чтобы бизнесу польза была.
Сначала вы жалуетесь на методы findSomethingBySomethingAndSomethingAndSomething, а потом мне втираете про list. Передавать в list DTO с фильтрами из интерфейса как вы описали это нормально. Но формировать в других местах эту DTO и вызывать этот же list - это дичь. И у меня сложилось впечатление, что вместо findSomethingBySomethingAndSomethingAndSomething вы формируете как раз DTO
Я прекрасно представляю как работает findByQuery. В конечном итоге у вас разрастется OrderListFilter и где-то в любом случае будут возникать баги из-за разного использования фильтров. Либо у вас разрастется OrderService на кучу методов. Тогда какой смысл в OrderService? Прослойка перед репозиторием с двумя методами? Тогда какой смысл в репозитории?
OrderListFilter только для случаев где реально требуется пагинация и фильтрация. Все остальные запросы в различных сервисах и джобах это отдельные методы в репозитории.
Для методов вида findSomethingBySomethingAndSomethingAndSomething() обычно получается так, что их становится много, а используются они только в одном месте кода.
Аргументом для findByQuery можно передавать специальный объект спецификации или просто настроенный QueryBuiler из ORM.
Ну и пусть будет куча методов findSomethingBySomethingAndSomethingAndSomething. Вполне может быть, что в этих find* могут появиться внутренние специфические фильтры.
Я писал код и с использование findByQuery и с использование findSomethingBy*. Второй вариант для нас был прозрачнее. Методов не так, чтобы прямо невозможно читать репозиторий. findByQuery используем, но чисто для GetList, для интерфейса, где есть список сущностей и фильтрация по полям, которых может быть спокойно и 15 и 20 (фильтрация по параметрам автомобиля например). Во всех остальных случаях findSomethingBy* из 3-4 элементов.
Ещё в плюс отдельных find* это фильтрация по датам. Где-то строго диапазон дат, где-то явное совпадение. Добавлять это всё в Query идея так себе. Query вырастет очень сильно и поддерживать его будет непросто.
Нет никаких точек расцвета. Просто если кто-то долго и упорно вколачивает себе в голову знания, то рано или поздно они упорядочиваются в систему. И человек просыпается утром и обнаруживает, что задачи над которыми еще вчера он бы потел и потом утирался, сегодня решаются на интитивном уровне.
А чем «просыпается утром и обнаруживает» отличается от точки расцвета автора?
Интересная статья. Какие будут Ваши действия, если истеричный клиент это постоянный и основной клиент компании, который снабжает всеми проектами? Каким образом можно аккуратно наладить работу с ним не доводя до расторжения всех контактов?
Соглашусь с titulusdesiderio и расширю ответ. Автор путает широту знаний и глубину. Если он знает только back, он backend'ер. Если front, то frontend'ер. Если он знает и то и то, то fullstack. Даже если он и то и то знает плохо, то это лишь означает, что он плохой fullstack. Это что касается широты. Что касается глубины — это стандартная градация junior, middle, senior. Автор пытается скрестить сеньора и тимлида, уровень знаний и уровень ответственности за отдел. Строго говоря это разные позиции. И заказчик (внутренний/внешний — не важно) в общем случае не может общаться с fullstack-разработчиком, потому что это обычный программист, пусть даже и сеньор, у которого не может быть функций управления отделом, управления загрузкой отдела и планирования. Максимум, что может быть это менторство. Автор описывает скорее неофициального тимлида, который стал таким из-за экономии на новом сотруднике или из-за того, что просто знал больше остальных сотрудников и захотел немного выделиться и больше участвовать в процессах управления. Но в целом fullstack != тому, кого описывает автор.
Слушайте, ну конкатенация строк тоже высокоуровневая абстракция. Не байты же мы объединяем. QueryBuilder достаточно низкий уровень. И если у вас сервис занимается составлением QueryBuilder и потом отправляет его в репозиторий, то это означает что слой с сервисом лишний. Пример isVip и 2 статуса не совсем корректный. И isVip и статусы это бизнес-свойства. Status.Platinum вполне себе бизнес-часть. Вот если если bool isVip, а в таблице tiny int is_vip, то пример был бы удачнее.
Но в любом случае формирование QueryBuilder в отдельном сервисе лично мне не нравится. Но вы делайте как вам удобно. Главное, чтобы бизнесу польза была.
QueryBuilder высокоуровневая абстракция? Яснопонятно. Переходим с интерфейсов на QueryBuilder. Аргументов больше не имею
Если формированием объекта занимается сервис, то это неправильно.
Сначала вы жалуетесь на методы findSomethingBySomethingAndSomethingAndSomething, а потом мне втираете про list. Передавать в list DTO с фильтрами из интерфейса как вы описали это нормально. Но формировать в других местах эту DTO и вызывать этот же list - это дичь. И у меня сложилось впечатление, что вместо findSomethingBySomethingAndSomethingAndSomething вы формируете как раз DTO
Я прекрасно представляю как работает findByQuery. В конечном итоге у вас разрастется OrderListFilter и где-то в любом случае будут возникать баги из-за разного использования фильтров. Либо у вас разрастется OrderService на кучу методов. Тогда какой смысл в OrderService? Прослойка перед репозиторием с двумя методами? Тогда какой смысл в репозитории?
OrderListFilter только для случаев где реально требуется пагинация и фильтрация. Все остальные запросы в различных сервисах и джобах это отдельные методы в репозитории.
Ну и пусть будет куча методов findSomethingBySomethingAndSomethingAndSomething. Вполне может быть, что в этих find* могут появиться внутренние специфические фильтры.
Я писал код и с использование findByQuery и с использование findSomethingBy*. Второй вариант для нас был прозрачнее. Методов не так, чтобы прямо невозможно читать репозиторий. findByQuery используем, но чисто для GetList, для интерфейса, где есть список сущностей и фильтрация по полям, которых может быть спокойно и 15 и 20 (фильтрация по параметрам автомобиля например). Во всех остальных случаях findSomethingBy* из 3-4 элементов.
Ещё в плюс отдельных find* это фильтрация по датам. Где-то строго диапазон дат, где-то явное совпадение. Добавлять это всё в Query идея так себе. Query вырастет очень сильно и поддерживать его будет непросто.
Может человек развивается в доте?) Читает гайды, смотрит записи игр, анализирует свои ошибки.
ntsaplin Что вы имели ввиду под «Российская поддержка — одна из лучших в мире.»?
Думаю автор имел ввиду не только количество исполненных тикетов, но и качество
Правильно ли я понимаю, что чем меньше люди получают, тем лучше работают?
А чем «просыпается утром и обнаруживает» отличается от точки расцвета автора?