业务逻辑异常。例如

时间:2012-05-11 23:07:14

标签: exception-handling n-tier-architecture

我在我的3层应用程序中有这个场景,其中一个服务层用于MVC表示层:

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

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

我在考虑两个选项:

1)进行另一项操作,询问是否有一名员工为新员工提供了相同的电子邮件。

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

我认为这是我认为最适合或最适合问题的问题。 我提出1)选项,因为我认为这是一个验证问题。 但是2)选项只需要对服务进行 1 调用,因此其(?)效率更高。

您怎么看?

谢谢!

2 个答案:

答案 0 :(得分:3)

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

  • 正如您所提到的,它避免了对服务的1次调用
  • 只需一种员工创建方法即可保持服务界面清洁
  • 从事务的角度来看它是一致的(异常意味着“事务失败”)。请记住,验证不仅是导致事务失败的众多原因之一。
  • 想象一下你的验证限制是否会发展(例如:其他员工属性......),你不会希望让所有的实现都为此而进化。

要记住的事情:确保使您的例外详细到足以清楚地确定失败的原因。

答案 1 :(得分:1)

如果通过“演示”层确实表示演示,则不应在该层中创建新员工。您应该只准备在HTTP响应对象中干净地呈现的任何数据。

通常,考虑此类问题的一种好方法是考虑服务对象在命令行程序调用时应该执行的操作:

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

在这里有一些调用服务的终端管理层。该服务可以实现另一个用户使用相同的电子邮件,并抛出适当的异常(即DuplicateUserException)。然后终端管理层解释该异常并打印出"Error! " + exception.getMessage();

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