7

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

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

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

来自 Spring 文档：

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

4

1 回答 1

11

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 为您处理它。:-) 您只需要担心您的业务实体。
于 2012-07-15T23:40:42.783 回答