Obsługa nowego interfejsu Date &Date API z JDBC jest zdefiniowana w JEP 170:JDBC 4.2 . Postgres strona pobierania zgodność z nowymi funkcjami JDBC 4.2 zaczyna się dopiero od wersji Postgres 9.4, więc niektóre wyzwania dotyczące zgodności pojawią się przy użyciu nowego interfejsu API ze starszymi sterownikami.
Nawet setObject(1, new java.util.Date()); jest odrzucany przez to samo ograniczenie w Postgres (które jest szczęśliwie akceptowane przez MySQL), nie tylko nowe API, takie jak LocalDate . Niektóre zachowania będą zależne od implementacji, więc tylko java.sql.* jest gwarantowane (w przybliżeniu).
Jeśli chodzi o framework Spring JDBC, myślę, że nadpisanie jego zachowania działa, aby obejść go bez późniejszego żałowania. Proponuję nieco inne podejście do tego, co już zrobiłeś:
- Rozszerz
BeanPropertySqlParameterSourcezachowanie do pracy z nowym API daty i czasu oraz innymi klasami powiązanymi z parametrami wejściowymi, jeśli to konieczne (nie jestem zaznajomiony z tym API Spring). - Wyodrębnij już nadpisane zachowanie
BeanPropertyRowMapperdo innej klasy do operacji pobierania. - Opakuj to wszystko wzorcem fabrycznym lub klasą użytkową, aby nie musieć na nie patrzeć ponownie.
W ten sposób zwiększysz przyszłe możliwości refaktoryzacji, jeśli interfejs API zostanie obsługiwany i zmniejszysz ilość kodu potrzebnego podczas rozwoju.
Możesz także spojrzeć na niektóre DAO podejścia.
