[attheicearcade]

I prefer the first example, to be honest. Much of the time your API is more or less a wrapper around the DB, so why introduce more indirection? I don’t really buy the testing argument since the interesting stuff which really needs testing is often in the queries anyway. Swapping out dependencies is not a huge issue in a language like rust, the compiler gives you a checklist of things to fix. I also don’t like that you call this function which handles transactions internally, inevitably you’ll end up with a handler calling two different functions like this resulting in two transactions when they should be atomic.

At $work we’re slowly ripping out a similar system in favour of handlers calling database functions directly, such that they can put transactions in the right place across more complicated sets of queries. Code is simpler, data integrity is better.

[globular-toast]

It's not really about being able to swap out the db or something, that's just a bonus. It's about being able to write a proper domain model (ie. entities and business rules etc.) that is clear and testable and independent of details like persistence, serialisation, i/o protocols etc. If your system is just CRUD, then you absolutely don't need anything like this, but if you have business rules (high level stuff) and intermingle it with low level details then it quickly becomes a mess that is hard to reason with.

But you should totally do what you're doing until it breaks. You only start looking into better architecture when things are not working. Being aware of something like this means you'll have something to look up if/when you run into the problems that inevitably crop up in simple "db wrapper" type APIs.

[mrkeen]

It is for testing, but you don't indirect over class A because you want to test class A, you do so to test class B.

By all means, write a test to make sure the queries actually work on the database. It will be slow, stateful and annoying, but still probably worth it.

But you don't want to bring that slow-statefulness over to every other upstream test in the entire system: want to test if the permission system (in some outer class) is allowing/blocking correctly? You'll need to start up a database to do so. Is your test making sure that an admin with permissions can create a user (without error?), well it's going to start failing due to USER_ALREADY_EXISTS if you run the test twice. To avoid that you'll need to reset and configure its state for every single invocation.

[LargeWu]

> To avoid that you'll need to reset and configure its state for every single invocation.

Good testing frameworks just do this for you.

I generally prefer focusing testing efforts around what you describe - spinning up the entire system under test - because that's how the system is used in real life. There's definitely times you want to test code in isolation statelessly, but I find that engineers often err on the side of that too much, and end up writing a bunch of isolated tests that can't actually tell you if an http call to their API endpoint performs the correct behavior, which is really what we want to know.

[Kinrany]

> Much of the time your API is more or less a wrapper around the DB, so why introduce more indirection?

That's an easy scenario. General utilities should aim to make hard things possible and then minimize the overhead in easy scenarios, so the fact that this is more complex than the dumbest thing that could possibly work, is not by itself a good argument against.