Comments 8
Другой разработчик, когда ему понадобится выбрать пользователей по имени, видя в базе кода вашу getById, скопипастит ваш код рядышком, немного подправит и сделает getByName.
Я правильно понимаю?
Точно такой-же копипастинг, как и просто использование TypedQuery. Только появляется прокладка-велосипед.
Если же вы предложите не имплементировать getById, а прямо писать этот кусок в классе бизнес-логики, то это грубейший залет. Проникновение деталей реализации в бизнес-код.
Правильно - реализация репозитория с методами UserRepository.getById, UserRepository.getByName, UserRepository.getByFamilyName и так далее. Хоть с сотней методов. И да, если они написаны копипастом с небольшими изменениями, ничего страшного.
Целиком и полностью согласен о вынесении в репозиторий. Нет, конечно не предлагаю выносить этот код в БЛ, это залёт. Что я предложил -- способ вынести рутинное (логирование, обработку ошибок, перформансные улучшения и пр.) в отдельный кусок логики. Просто показал на примере кода, который часто вслепую копируют, потому что блоки try-with-resources обязывают держать, собственно, ресурсы внутри себя.
Конечно, подход с матрёшкой методов (внутри каждого try) тоже имеет место, но описанный выше подход мне кажется более наглядным и выпячивающим суть каждого запроса, при этом прячущим остальное под ковёр.
Ну и стандартные плюсы про одну точку изменений, разделение ответственности, однообразность кода и пр.
Да и в принципе шаговый билдер не только про БД, он про любой кусок сложной последовательно требующей новых данных логики, порядок выполнения которой строг. Всё. А что это будет, запрос, кусок бизнес-логики или рецепт пирога -- неважно.
Да в принципе нормально, прочитал код с интересом. Просто с базами данных - это такая заезженная тема, что там трудно что-то придумать.
Формирование объекта-алгоритма с заданием последовательности действий? Действия со счетом например. Сначала то, потом это, задать параметры, выполнить то и так далее. Да, спасибо за идею, надо подумать.
Чем то напомнило реактивные пулы на vert.x + mutiny - https://quarkus.io/guides/reactive-sql-clients#using
или hibernate reactive на том же mutiny
Использую этот шаблон, он действительно местами очень классно применим, спасибо, что популяризируете :)
Я что-то подобное делал для решения N+1 у Hibernate и для реализации batch insert в одном запросе. В итоге не смог победить вменяемую отдачу id при возникновении конфликтов при insert.
Похоже, очень много кто его использует, хотя и без сильной огласки, придя к шаблону самостоятельно. Оно и понятно -- я тоже придумал такое всего за ночь (и сразу побежал с этим на Хабр, ха-ха), так что, единственное что я мог предложить нового -- сделать инструмент иммутабельным. А так, получается как написал комментатор выше -- статья просто популяризует подход. Ну да и хорошо, главное, работает)
Заметаем рутину под ковёр. Шаблон Step Builder в Java