Похоже, очень много кто его использует, хотя и без сильной огласки, придя к шаблону самостоятельно. Оно и понятно -- я тоже придумал такое всего за ночь (и сразу побежал с этим на Хабр, ха-ха), так что, единственное что я мог предложить нового -- сделать инструмент иммутабельным. А так, получается как написал комментатор выше -- статья просто популяризует подход. Ну да и хорошо, главное, работает)
Целиком и полностью согласен о вынесении в репозиторий. Нет, конечно не предлагаю выносить этот код в БЛ, это залёт. Что я предложил -- способ вынести рутинное (логирование, обработку ошибок, перформансные улучшения и пр.) в отдельный кусок логики. Просто показал на примере кода, который часто вслепую копируют, потому что блоки try-with-resources обязывают держать, собственно, ресурсы внутри себя.
Конечно, подход с матрёшкой методов (внутри каждого try) тоже имеет место, но описанный выше подход мне кажется более наглядным и выпячивающим суть каждого запроса, при этом прячущим остальное под ковёр.
Ну и стандартные плюсы про одну точку изменений, разделение ответственности, однообразность кода и пр.
Да и в принципе шаговый билдер не только про БД, он про любой кусок сложной последовательно требующей новых данных логики, порядок выполнения которой строг. Всё. А что это будет, запрос, кусок бизнес-логики или рецепт пирога -- неважно.
Похоже, очень много кто его использует, хотя и без сильной огласки, придя к шаблону самостоятельно. Оно и понятно -- я тоже придумал такое всего за ночь (и сразу побежал с этим на Хабр, ха-ха), так что, единственное что я мог предложить нового -- сделать инструмент иммутабельным. А так, получается как написал комментатор выше -- статья просто популяризует подход. Ну да и хорошо, главное, работает)
Спасибо, прочту. Возможно, подобные подходы использовались и там, за 12 лет можно найти применение
Целиком и полностью согласен о вынесении в репозиторий. Нет, конечно не предлагаю выносить этот код в БЛ, это залёт. Что я предложил -- способ вынести рутинное (логирование, обработку ошибок, перформансные улучшения и пр.) в отдельный кусок логики. Просто показал на примере кода, который часто вслепую копируют, потому что блоки try-with-resources обязывают держать, собственно, ресурсы внутри себя.
Конечно, подход с матрёшкой методов (внутри каждого try) тоже имеет место, но описанный выше подход мне кажется более наглядным и выпячивающим суть каждого запроса, при этом прячущим остальное под ковёр.
Ну и стандартные плюсы про одну точку изменений, разделение ответственности, однообразность кода и пр.
Да и в принципе шаговый билдер не только про БД, он про любой кусок сложной последовательно требующей новых данных логики, порядок выполнения которой строг. Всё. А что это будет, запрос, кусок бизнес-логики или рецепт пирога -- неважно.