我试图理解这些对象在松散耦合系统方面的差异。业务对象与实体对象相同吗？我可以使用 MVC 中的业务或实体对象作为我的命令对象吗？命令对象与表单对象相同吗？只是寻找 Spring 术语和用法中对象类型的说明。
我在 stackoverflow 上发现了一些问题，但没有一个能按照我的喜好解释它。
Spring Web MVC 文档似乎说您可以使用业务（实体？）对象作为命令/表单对象，但这不会违背关注点分离吗？
来自 Spring 文档：
可复用业务代码，无需重复。使用现有的业务对象作为命令或表单对象，而不是镜像它们来扩展特定的框架基类。
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 会为你处理它。 :-) 您只需要担心您的业务实体。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
