SQLAlchemy托管会话中两种对象创建模式的弊端分析

假设我们要创建MyClass类的新对象并添加到数据库，存在以下两种实现方式，各自存在不同的弊端：

方式一：先构建对象，再开启会话添加 #

class MyClass:
    pass
def builder_method_for_myclass():
    # 此处包含大量代码..
    return MyClass()

my_object=builder_method_for_myclass()
with db.managed_session() as s:
    s.add(my_object)

该方式仅在添加新对象时保持会话开启，弊端包括：

• 如果MyClass是ORM映射类，部分ORM框架要求对象必须绑定到会话才能初始化关联属性或延迟加载字段。若构建过程中涉及这类操作，会直接报错，因为此时对象还未关联任何会话。
• 若构建过程中需要临时查询数据库（比如根据已有数据计算对象属性），这种模式下要么得额外开启临时会话，要么无法直接复用后续的添加会话，增加了会话管理的复杂度，还可能引发事务一致性问题（比如临时会话查询的数据和后续添加会话的数据不在同一个事务里，出现数据不一致）。
• 构建完成到会话开启之间存在时间差，如果对象属性被意外修改，会导致最终存入数据库的数据和预期不一致，且这种修改难以追踪。

方式二：在会话内完成对象构建 #

class MyClass:
    pass
def builder_method_for_myclass():
    # 此处包含大量代码..
    return MyClass()

with db.managed_session() as s:
    my_object=builder_method_for_myclass()

该方式在托管会话内调用并执行整个构建方法，弊端包括：

• 会话持有时间过长：如果构建方法包含大量耗时操作（比如文件IO、第三方API调用、复杂计算），会导致数据库会话长期处于开启状态，占用数据库连接池资源，影响其他请求的连接获取，甚至引发连接超时或池耗尽问题。
• 事务范围不合理：会话通常绑定事务，构建过程中的任何异常都会导致整个事务回滚，但很多时候构建失败并不需要回滚数据库操作（比如只是构建参数错误，根本没涉及数据库读写），扩大了事务回滚的范围，增加了不必要的数据库开销。
• 构建逻辑与会话耦合：如果构建方法原本不需要依赖数据库会话，这种写法会强制它处于会话上下文内，降低了构建方法的可复用性——比如后续想在非数据库场景下复用这个构建方法，就必须额外创建空会话或者修改方法逻辑。

内容的提问来源于stack exchange，提问作者KZiovas