如何编写可以在直接数据模型更改和挂起的对话框更改中重用的复杂验证和业务逻辑？

Question

我希望得到一些建议：

我需要为中等大小的java / Swing应用程序设计一个软件解决方案。

该应用程序将有大约200个需要复杂数据验证和业务逻辑的用例。

通常，这是我通常的设计：

• 为每个用例创建一个简单的POJO，并在其执行方法中使用自定义构造函数、自定义验证和业务逻辑。这些操作包含简单而复杂的数据验证，如所需字段、唯一名称和更复杂的约束。
• 为每个用例创建一个具有方法的控制器。每个方法都接受自定义参数，构造并执行它的相关操作。
• 为了简单起见，我将不提及有关数据模型通知或操作排队机制的细节。

这个解决方案过去起了作用，因为它鼓励所有开发人员重用现有的控制器方法和验证，但是：

新的应用程序将广泛使用对话框进行数据输入；

这些对话框将实现与控制器实现的相同的复杂数据验证和业务逻辑，但是在单击OK按钮之前，对话框不会更新数据模型。

我讨厌为同一个复杂的验证和业务逻辑编写多个版本的想法，因为它引发了维护噩梦。

如何对标准数据模型更改和“挂起”对话框更改执行复杂的业务逻辑和验证，假设对话框在单击OK按钮之前不会提交更改？

数据模型可能相当大，因此创建内存中的克隆和控制器似乎是不可行的。

有人有什么建议吗？如果是的话，我将永远欠你的债。

Answer 1

我不想在我的数据模型对象中包括验证。我使它们变得非常简单，不了解值的内容、驱动它们的业务逻辑以及应用程序的状态。

我已经创建了独立于控制器和数据模型的验证类。在导入数据和根据输入的有效性执行条件突出显示的UI期间使用这些方法。当单元格表中的数据与预期的输入不匹配时，我把它的背景变成浅红色。这是一个简单的问题，就是有一系列能够验证不同输入的类，然后在构造时将它们与适当的输入字段/单元相关联。它们非常直接，而且在数据导入过程中非常容易使用。请注意，在数据导入期间，我只记录预期数据中的错误，然后允许用户修改不正确的数据。我本可以很容易地选择完全拒绝进口。

希望这能有所帮助。

Answer 2

我设计我的模型，这样他们就不会轻易陷入无效状态。然后，当我的接口(UI或服务)尝试将其置于这种状态时，会抛出一个错误，然后我可以将该错误发送回违规的源。

在大多数情况下，这意味着我的模型有一个名为isValid()的方法，该方法检查自己无法通过setter检查的内容。此方法还处理包含更多模型的更复杂的业务逻辑。

在多个地方重复的验证，我把它们抽象成实用函数xor验证类，这样我就不必复制和粘贴我的验证了。有时，我不得不编写更复杂的服务类型验证，但这是相当罕见的。

这使得我的模型相当厚实，然而，我知道，无论我在哪里使用该模型，都会带来验证。将验证保持独立，意味着必须始终记住进行验证，这可能导致程序员出错。这也会使我的接口(UI、SOAP、JSON等)变得更薄，因为它侧重于从输入转换到模型，并响应模型更改，包括验证错误。

在UI接口中，在向驻留在服务器上的模型发送数据之前，我将对类型、范围等进行一些基本检查。在某些情况下，在性能决定的情况下，我会将一些验证移到UI中，但只在性能决定的情况下。

这并不意味着我的模型也是铁板一块的。我将我的验证分解成可组合的单独的部分，我在我的模型中调用它们。这仅仅意味着验证本身对模型用户是隐藏的。

Answer 3

您有一个域模型，它封装了验证和业务逻辑，这并不是坏事。

考虑一下‘六角形’架构对你的设计意味着什么。具体来说，它将建议您为持久层设计一个接口，允许将不同的持久性机制作为适配器插入。

当实际执行业务逻辑时，请使用数据库适配器。

在运行虚拟运行的业务逻辑时，要检查验证规则，请使用不写回数据库的虚拟适配器，如果运行得太远，只会给出一个OK，如果没有，则会有一些验证异常退出。

现在，您的域模型可以在这两种情况下使用，允许您重用代码。