【问题标题】:Is Business Validation in a Value Object acceptable?值对象中的业务验证是否可接受?
【发布时间】:2014-10-28 09:21:13
【问题描述】:

我们有一个多租户应用程序,无论好坏,它通过大量的 if-then-else 语句处理不同客户之间的区别。我有一个特别简单的验证,需要对类似于以下场景的数据输入执行:

假设我们有一个名为Thermometer 的对象和一个名为temperature 的属性。当用户输入一个数字时,我们需要将其四舍五入到最接近的小数点后 3 位。因此,如果他们输入“65.65432”,我们需要存储“65.654”。但是等等,还有更多。客户 Bob 喜欢细节,不希望数字四舍五入。客户 Sarah 是请求四舍五入的人。

如何做到这一点很简单,但 在哪里 做到这一点是我的问题。我想直接在值对象Thermometer 上执行此操作,因为它快速简单,而且似乎 正确。然而,由于只有一个客户请求它,这属于“业务逻辑/验证”的领域。将它放在值对象上是否仍然可以接受,或者我应该把它吸起来并在表示层中构建它?这样做需要将访问器包装在处理 UI 的托管 bean 中的代理方法中。哪个选项有更好的回报?

更多详情
对于任何感兴趣的人,这是一个带有 JSF 的 J2EE 应用程序。我们通常可以使用<f:numberConverter>,但在这种情况下,我们也使用<a4j:support event="onkeyup" ajaxSingle="true" />,这似乎破坏了numberConverter。所以我们必须手动进行舍入。

【问题讨论】:

  • 我投票赞成尽可能在 UI 中执行验证
  • 那么,您现在如何区分客户?用户会话?配置文件?我会使用这些,但我不知道你是否能够。
  • 问题不在于如何区分客户端。这是微不足道的,因为我们一直这样做。出于讨论的目的,假设我们有一个函数isUserSarah()。在我试图解决的现实问题中,我可以从嵌套属性中获取客户端。
  • 注意:我没有在这个问题中添加 JSF 标签,因为它不是 JSF 特有的,使用 JSF 也不影响解决方案。 “更多细节”只是为了排除“让您的演示框架处理它”的答案,它实际上强化了 JSF 在这里无关紧要。

标签: design-patterns enterprise paradigms


【解决方案1】:

当然,您希望在不同的类中对不同的需求进行建模,这些需求可以根据客户端进行插入。类似策略的东西。这样您就可以独立地对每个单元进行单元测试,并保持良好的低耦合度。

【讨论】:

    最近更新 更多