【问题标题】:Business logic exception.example业务逻辑异常.example
【发布时间】:2012-05-20 12:55:21
【问题描述】:

我在我的 3 层应用程序中遇到了这种情况,其服务层服务于 MVC 表示层:

我有一个操作,例如创建一个员工,其电子邮件在员工集中必须是唯一的。这个操作是通过一个服务在 MVC 表示层中执行的。

如何管理创建已在数据库中为其他员工注册电子邮件的员工的意图?

我正在考虑两种选择:

1) 有另一个操作来查询是否有员工为新员工提供了相同的电子邮件。

2) 在 CreateEmployee 服务中为重复的电子邮件抛出异常。

我认为这是我认为最适合或最适合该问题的问题。 我建议 1) 选项,因为我认为这是一个验证问题。 但是 2) 选项只需要 1 调用服务,因此它的 (?) 更有效。

你怎么看?

谢谢!

【问题讨论】:

    标签: exception-handling n-tier-architecture


    【解决方案1】:

    如果您所说的“演示”层真的是指演示,那么您不应该在该层创建新员工。您应该只准备在 HTTP 响应对象中清晰呈现的任何数据。

    一般来说,考虑此类问题的一个好方法是考虑服务对象在被命令行程序调用时应该做什么:

    > createEmployee allison.brie@awesome.com
      Error! 'allison.brie@awesome.com' is already registered.
    

    其中有一些终端管理层调用该服务。该服务会采取一些措施来实现另一个用户使用相同的电子邮件,并引发适当的异常(即DuplicateUserException)。然后终端管理层解释该异常并打印出"Error! " + exception.getMessage();

    也就是说,请注意您的两个选项实际上是相同的选项。您的服务仍必须查询数据库中的重复项。虽然这是“验证”,但它不是输入验证。输入验证意味着检查它是否是有效的电子邮件地址。 (是否有“@”符号和有效的 TLD?)

    【讨论】:

    • 我的意思是从表示层创建一个员工。我真的很喜欢解决问题的观点。我没想到 CreateEmployee 也必须查询重复项,这确实是一个问题。因为如果我认为在两个事务中 ExistsEmployee 和 CreateEmployee 连续执行,第一个可能会成功,但第二个不会,因为在中间可能已经创建了另一个 Employee,例如,另一个用户。谢谢!
    • 您的服务层应该提供幂等功能来执行它们指定的数据操作。一旦验证输入是有意义的,表示层应该简单地调用服务层。如果存在输入错误的业务规则,服务层应该报告 - 例如重复的电子邮件地址。然后表示层应该只知道如何处理指定的失败案例(即每种异常类型)。
    • 我明白了。正如你所说,我将mek服务层幂等的功能,我忘记或没有真正理解这一点。非常感谢!
    【解决方案2】:

    我肯定会选择第二种选择:

    • 正如您所说,它避免了对服务的 1 次调用
    • 只用一种创建员工的方法就可以保持服务界面整洁
    • 从事务的角度来看是一致的(异常意味着“事务失败”)。请记住,验证不仅是导致交易失败的众多原因之一。
    • 想象一下您的验证约束会演变(例如:其他员工属性...),您不会希望您的所有实施都只为此而演变。

    记住一点:确保让您的异常足够详细,以便清楚地确定失败的原因。

    【讨论】:

    • 我喜欢您推荐中的 4 点。我正在考虑在最初的 2 组 DataAccessExceptions 和 BusinessLogic 异常中进行自定义异常。谢谢!
    • 干杯,投票 :) 确定抛出哪种异常可能很棘手。根据我的经验,为了保持简单和不断发展,您通常只需要服务抛出两种类型的异常:说明服务遇到技术问题(可能是 InternalException,因为 DataAccessException 通常保留给模型层),另一种说明我们没有满足业务需求(BusinessLogicException 看起来不错)。在 BusinessLogicException 中,您可能会遇到一系列错误(例如:errors.put("email", "ALREADY_EXISTS")
    • 哈哈,你读懂了我的想法!到目前为止,我一直在尝试实现自定义错误处理,但没有成功。我担心的一个问题是我应该抛出多少种异常。我真的很感谢你的回复!我将在 SO 中再提出一个问题,因为我真的无法让 ErrorHandler 工作。谢谢!
    猜你喜欢
    • 2016-11-14
    • 1970-01-01
    • 2023-04-01
    • 2012-07-18
    • 1970-01-01
    • 2010-10-12
    • 2019-12-25
    • 1970-01-01
    • 2012-02-09
    相关资源
    最近更新 更多