C# ASP.NET Web API REST包装器开发：创建记录独立提交问题

问题详情 #

我们现有三个独立的REST API接口：创建记录、验证记录、确认记录。原流程是前端先创建一条未验证的基础记录并展示，用户确认时先调用验证接口，根据验证结果再调用确认接口。

现在需要开发一个包装API，把这三个步骤合并成一个接口调用，但要求即使验证或确认步骤失败，创建记录的操作必须成功。

当前我们使用自定义的UnitOfWork ActionFilterAttribute，一旦流程中出现失败，创建操作也不会提交。请问这种情况下，我们应该选择调用原有独立API，还是可以在创建记录步骤完成后先提交，再执行后续的验证和确认步骤？技术栈是C#、NHibernate + 自定义UnitOfWork ActionFilterAttribute。

解决方案建议 #

方案1：拆分事务，创建后立即提交 #

这是最贴合需求的方案：

• 在包装API的逻辑中，先执行创建记录的代码，手动触发NHibernate事务提交（可以临时绕过全局的UnitOfWork ActionFilterAttribute，或者在创建逻辑的方法上单独配置独立的UnitOfWork），确保记录持久化到数据库。
• 提交完成后，再独立执行验证和确认逻辑，这两步的失败不会回滚已提交的创建操作。
• 关键注意点：
  • 确保创建操作的事务是独立的，和后续步骤的事务上下文完全隔离。比如通过手动管理ISession和ITransaction，或者给创建方法标记专属的UnitOfWork特性。
  • 验证/确认失败时，要做好日志记录，必要时可以在已创建的记录中标记“验证失败”或“确认失败”的状态，方便前端展示和后续处理。

方案2：调用原有独立API #

复用现有成熟逻辑，天然隔离事务：

• 包装API内部按顺序调用三个独立接口：先调用创建接口（创建接口自身的UnitOfWork会保证提交成功），再调用验证接口，最后调用确认接口。
• 这种方式下三个步骤的事务完全独立，创建操作的成功不会被后续步骤的失败影响。
• 关键注意点：
  • 要处理接口调用间的异常，比如创建成功后验证接口调用失败，需捕获异常并返回明确的响应给前端，同时确保创建记录的状态不受干扰。
  • 如果原有API是内部服务接口，建议直接调用服务层方法而非HTTP请求，避免不必要的网络开销。

方案选择 #

• 若原有三个接口逻辑稳定、复用性高，优先选方案2，减少重复开发成本。
• 若追求性能（避免内部API调用开销）或需要更精细的事务控制，选方案1，直接在服务层拆分事务完成操作。

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