I find JdbcTemplate / TransactionTemplate to be more procedural, so now you've got code that focuses on the HOW when if you use declarative transaction management and Hibernate right, the code focuses on the WHAT. Do it right and the latter is more readable, more maintainable. Do it wrong and... well, you found that out.
Your code needs to live for many more years and people other than yourself will need to work on it. I think your decision to drop Hibernate and declarative transaction management might be beneficial in the short term, but could bite you in the long term. You've introduced lots of boilerplate code that may have bugs (or others may inadvertently introduce them).
The point with declarative is that it is nice until it isn't and it breaks on you. I've cleaned up a fair amount of very misguided uses of the @Transactional annotation on several projects where people were using it as some sort of magical incantation on anything that looked like it might be doing anything with a database.
TransactionTemplate has about the same amount of verbosity but it doesn't lie and it gives you explicit control. I consider this more maintainable. Also compile time type checking vs. runtime injection of code has certain advantages. Annotations are very opaque in what they actually cause to happen at run time. One rogue annotation can really ruin your day.
I'm not alone. The Spring people are rolling back a lot of their fondness for annotation based declarative magic in favor of using kotlin based functional DSLs. E.g. the kofu project gets rid of essentially all of them in Spring Boot without really increasing verbosity. There are a lot of benefits. Start up time improves, it's easier to use Graal (no reflection/aop magic), it's easier to debug (just command click the function names, set break points, etc.). And it does exactly what it says.
Currently kofu is labelled as experimental but it's clearly the way to go. No more magical proxies that break in completely non magical and convoluted ways.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"I like code that does what it says."
I find JdbcTemplate / TransactionTemplate to be more procedural, so now you've got code that focuses on the HOW when if you use declarative transaction management and Hibernate right, the code focuses on the WHAT. Do it right and the latter is more readable, more maintainable. Do it wrong and... well, you found that out.
Your code needs to live for many more years and people other than yourself will need to work on it. I think your decision to drop Hibernate and declarative transaction management might be beneficial in the short term, but could bite you in the long term. You've introduced lots of boilerplate code that may have bugs (or others may inadvertently introduce them).
The point with declarative is that it is nice until it isn't and it breaks on you. I've cleaned up a fair amount of very misguided uses of the
@Transactionalannotation on several projects where people were using it as some sort of magical incantation on anything that looked like it might be doing anything with a database.TransactionTemplate has about the same amount of verbosity but it doesn't lie and it gives you explicit control. I consider this more maintainable. Also compile time type checking vs. runtime injection of code has certain advantages. Annotations are very opaque in what they actually cause to happen at run time. One rogue annotation can really ruin your day.
I'm not alone. The Spring people are rolling back a lot of their fondness for annotation based declarative magic in favor of using kotlin based functional DSLs. E.g. the kofu project gets rid of essentially all of them in Spring Boot without really increasing verbosity. There are a lot of benefits. Start up time improves, it's easier to use Graal (no reflection/aop magic), it's easier to debug (just command click the function names, set break points, etc.). And it does exactly what it says.
Currently kofu is labelled as experimental but it's clearly the way to go. No more magical proxies that break in completely non magical and convoluted ways.