Велосипед для извлечения данных

[terryP]

1. Если тесты настроены правильно, то намного лучше если упадет Exception в тестах, чем вдруг исчезнет значения полей в продакшене. Намного логичнее не съедать ошибки, а сделать unit тесты базы, которые при неверном типе колонки просто не дадут собрать билд. Естественно, unit тесты должны покрывать все сущности (например, банально обходит все DAO классы рефликсией и проверять что ни один метод не упадет на тестовой схеме).

2. Exception дорогое удовольствие по производительности, почему не использовать getObject(int columnIndex), а потом уже в рантайме не определять какой тип вы получили? Зачем обязательно все делать через игнорирование SQLException?

[sah4ez32]

1. Unit тесты — это святое, но они не могут обеспечить проверку при упавшем подключении к БД. И unit тесты не должны проверять работу с базой данных. Ну в нашем случае у нас не было возможности подымать тестовые бд. Кровавый энтерпрайз он бывает разный.

   
   
2. Встает вопрос как часто может выскочить SqlException. И было желание использовать рефлексию для определения колонки откуда брать данные. Но как предложили в [комментарии] (https://habrahabr.ru/post/318740/?mobile=no#comment_9989940) велосипед уже давно придумано и есть смысл посмотреть это решение.

[tigraboris]

Ой, а поясните почему юнит тесты не должны проверять работу с бд? например модуль, отвечающий за соединение с бд?

[sah4ez32]

Ну если модуль работы с БД, то можно проверять строку подключения, и то если оно не получается из пула соединений.

Классический вариант юнит теста — это проверка работы всех методов класса, без работы с другими классами, а где надо обращение к другому классу, пишутся mock.

Но после реакции на эту статью, я уже ни в чем не уверен.

[igor_suhorukov]

Можно упростить жизнь и избегать велосипедостроительства при работе с JDBC через Spring JdbcTemplate… Даже не нужен весь спринг, только этот модуль. Производительность будет та же, кода меньше…

[gvassilev]

Где логи (смущает пустой catch), как узнать что именно пошло не так и где? Дублирование кода никак не «чистый код» (getInt и getIntNull). Дефолтное значние я бы передавал параметром и то, в отдельном методе.
id = ex.getInt(«id»); с ID вообще зло, ибо последвстия мержа положат систему.

[evkin]

Как по мне проще сеттить поля в объект просто вызывая все методы подряд в одном блоке try-catch и если в каком то поле вылетает ошибка в catch её отлавливать, логгировать и возвращать новый пустой объект без инициализации любых полей (со значения по умолчанию), чем возвращать полуинициализированый обьект. если пойти дальше, то брать индексы, а лучше названия полей и положить их в аннотацию, которую будет парсить соответствующий обработчик (executor). А если идти еще дальше, то открыть для себя MyBatis и делать это через него вызывая слой дао в том же try-catch описанном выше))

[sah4ez32]

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

[terryP]

В Java ни в одной области нет одного общеизвестного решения, десятки вебфреймворков, десятки библиотек работы с JSON и т.д. И это хорошо, так как у каждого проекта свои задачи и цели. Есть огромное количество различных решений работы с БД от JPA и hibernate до jOOQ и Spring's JdbcTemplate. Писать свои велосипеды явно не стоит.

[sah4ez32]

Эх… и у в нашей Греции есть все… прочитай я Вашу статью раньше, может и не писал бы статью, и не делал велосипеда.

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

[gkislin]

Вот вам пара ссылок, чтобы велосипедов не писать:
Lightweight JDBC helper library
Маппинг объектов в базы данных

[sah4ez32]

спасибо за ссылки. сейчас будут выходные, надо будет попробовать разные варианты.