【问题标题】:Generating Spring DataAccessExceptions with legacy frameworks使用遗留框架生成 Spring DataAccessExceptions
【发布时间】:2012-01-06 05:05:01
【问题描述】:

我目前正在重写一个后端正在使用的遗留 Web 应用程序,其中包括 CORBA 和另一个 RPC 框架 - 两者都很老旧并且不支持 Spring。

我希望我最终可以编写一个 @Repository 类来处理 CORBA 和其他 RPC 调用,并用某种 DataAccessException 包装它们的所有异常,然后将其抛出。

我的问题是

  1. 是否有最佳实践来说明如何执行此操作,以便我的存储库不会抛出太多DataAccessExceptions,特别是在同一存储库方法可以引发 CORBA 和 RPC 异常的区域?
  2. 是否应该有一个“低于”存储库类的类来处理其中的一些并将其抽象出来,或者从技术上讲,存储库类的用途是什么?

【问题讨论】:

  • 您的存储库是否适用于不同的实体类型?还是只有一个?
  • 不同。但我认为它们可能都使用相同的 NameComponent 名称。我想要为每个技术堆栈提供单独的存储库,甚至可能为我必须引用的每个 CORBA 对象类型创建存储库,并酌情在后端 ORB/RPC 代码中自动装配。

标签: java spring error-handling rpc corba


【解决方案1】:

鉴于社区没有回应,我想我会发布我的实现,这绝不是幸运的,甚至可能有点味道。

为了让调用我的业务层的代码(标有@Service 的类)只需担心一个异常(即DataAccessException),业务层或以下代码抛出的任何/所有异常都会被包装到某种形式的DataAccessException。这听起来很有趣的原因是业务逻辑可能会合法地抛出与数据访问无关的异常,例如验证。

但是,我的想法是不要用多个 catch 块或 try { ... } catch (Exception ex) { ... } 的反模式弄乱我的 servlet。

同样,这不是一个真正的答案,但我想它确实有效......

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-10-14
    • 1970-01-01
    • 2019-12-10
    • 2021-01-16
    • 2010-12-21
    • 1970-01-01
    相关资源
    最近更新 更多