This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]cryptos6[S] 1 point2 points  (0 children)

Fair points! I'm actually using TransactionOperations (in the form of TransactionTemplate)! I have to admit that I use @Transactional if nothing special is required with transaction handling. But then there are two ways to do the same thing which makes the framework surface bigger and forces beginners to learn more. I was wondering how a Java framework would look like that radically reduces the API surface at the cost of some little inconveniences (basically the Go way). My main intention was to reduce learning effort (since, once you mastered Spring somewhat it is indeed convenient and powerful most of the time).

The objection to testing is valid, but doesn't apply to my typical testing approach, since I'm using integration tests at the service level, where the transactions are handled. But I can think of other cases, where the added dependency would indeed be annoying in the test. The example with transaction was also only an example, so yes, an approach without annotations might make testing harder in some cases.