@brianb I'm all for keeping the routes/views as small as possible and moving all of the business logic and I/O away from them.

And recently I've going one step further, with separate classes for the logic, and other strictly from the I/O. The I/O classes are then used as pluggable dependencies for the logic ones.

@brianb for me this is not framework-dependent: a database connector object provides a pivot point for things like instrumentation & logging of database queries, database portability, sharding, etc. Almost always better to have one than not, *unless* you're still in a prototype phase where you're not really sure what the connector's responsibilities should be yet.

@brianb No flask experience, but I vote for the abstraction.