Spring 术语中的命令、表单、业务和实体对象之间的区别？

Question

我正试图围绕松散耦合系统方面的这些对象之间的差异。业务对象是否与实体对象相同？我可以使用 MVC 中的业务或实体对象作为我的命令对象吗？命令对象与表单对象相同吗？只是在 Spring 术语和用法中寻找对对象类型的澄清。

我在 stackoverflow 上发现了一些问题，但没有什么可以解释我喜欢的。

Spring Web MVC 文档似乎说您可以将业务（实体？）对象用作命令/表单对象，但这不违反关注点分离吗？

来自 Spring 文档：

可重用业务代码，无需重复。将现有业务对象用作命令或表单对象，而不是镜像它们以扩展特定的框架基类。

Answer 1

1) 从技术上讲，业务对象和业务实体（或您所称的“实体对象”）并不相同。

业务实体包含数据。而业务对象包含有关您的业务实体的逻辑（您如何创建实体，如何更新它等）。业务对象在技术上是一种旧的 J2EE 模式，我还没有在当前代码中真正看到它，所以我无法详细说明。有人会说业务对象对应于 DAO，也有人会说是服务。而有些开发者只是说业务对象和实体是一样的，因为他们认为“对象”和“实体”的粒度相同，或者因为他们的业务实体也包含逻辑，或者只是因为他们不知道。我只是更喜欢谈论包含数据的对象的“（业务）实体”，而我从不使用术语“业务对象”，因为它可以有不同的解释。

2) 根据 Spring MVC 文档，命令对象是一个 JavaBean，它将使用表单中的数据进行填充。另一方面，什么是表单对象，而不是支持表单的对象？

所以是的，命令对象在语义上与表单对象相同。我更喜欢术语表单对象，我发现它可以立即理解。

3) 正如您所说，根据 Spring MVC 文档，该框架的一个特性是

可重用业务代码，无需重复。 利用现有业务 对象作为命令或表单对象，而不是镜像它们来扩展 一个特定的框架基类。

所以是的，你可以——而且根据 Spring 的说法，你应该——使用业务实体作为命令/表单对象。如果您不相信，这里有一些原因：

• 为了简单起见。上帝知道我们的 Java 软件架构需要更简单。一些公司使用太多层来做非常简单的事情。在 Spring、Java（见下文）等的领导下，已经采取了许多措施来应对这种情况。
• 为了您自己，因为它使编程更简单、更轻松、更有趣
• 因为 Spring 和 Java（通过 JSR）都这么说。确实：我们对表单对象有什么期望？表单支持和可能的一些验证。我们将如何进行此验证？ Spring MVC 3 支持使用 JSR-303 @Valid 注解验证 @Controller 输入。我们将把约束放在哪里来验证？根据 JSR-303，存储这些约束（@NotNull、@Length 等）的最佳位置是业务实体本身。底线：最好使用业务实体作为您的命令/表单对象。
• 仍然尊重关注点的分离。只是一个问题（表单支持）不再是一个问题！ Spring MVC 为您处理它。 :-) 您只需要担心您的业务实体。