Spring术语中命令，表单，业务和实体对象之间的区别？
我试图在松耦合系统方面围绕这些对象之间的差异。 业务对象是否与实体对象相同？ 我可以在MVC中使用业务或实体对象作为我的命令对象吗？ 命令对象与表单对象相同吗？ 只是在寻找Spring术语和用法中对象类型的说明。
我在stackoverflow上发现了一些问题，但没有任何问题可以解释我的喜好。
Spring Web MVC文档似乎说你可以使用你的业务（实体？）对象作为你的命令/表单对象，但这不会违背关注点的分离吗？
来自Spring Docs：
可重复使用的业务代码，无需重复。 将现有业务对象用作命令或表单对象，而不是镜像它们以扩展特定的框架基类。
1）从技术上讲，业务对象和业务实体（或称为“实体对象”）并不相同。
业务实体包含数据。 业务对象包含有关业务实体的逻辑（如何创建实体，如何更新实体等）。 业务对象在技术上是一种旧的J2EE模式，我还没有在当前的代码中看到它，所以我不能详细说明。 有些人会说业务对象与DAO相对应，而其他人则更愿意说服务。 有些开发人员只是说业务对象和实体是相同的，因为他们认为“对象”和“实体”具有相同的粒度，或者因为他们的业务实体也包含逻辑，或者仅仅因为他们不知道。 我只是想讨论包含数据的对象的“（业务）实体”，而我从不使用术语“业务对象”，因为它可以有不同的解释。
2）根据Spring MVC文档，命令对象是一个JavaBean，它将填充表单中的数据。 另一方面，什么是表单对象，而是支持表单的对象？
所以，是的，命令对象在语义上与表单对象相同。 我更喜欢术语forms对象，我发现它立即可以理解。
3）正如你所说，根据Spring MVC文档，框架的一个特性是
可重复使用的业务代码，无需重复。 将现有业务对象用作命令或表单对象，而不是镜像它们以扩展特定的框架基类。
所以是的，你可以 – 而且你应该根据Spring使用业务实体作为你的命令/表单对象。 如果你不相信，这里有一些原因：
- 为了简单起见。 上帝知道我们的Java软件架构需要更简单。 有些公司使用太多层来做非常简单的事情。 在Spring，Java（见下文）和诸如此类的东西的带领下，已经采取了许多措施来解决这个问题。
- 为了您自己，因为它使编程更简单，更容易和更有趣
- 因为Spring和Java（通过JSR）说出来。 确实：我们对表单对象有什么期望？ 形成支持，可能还有一些validation。 我们如何进行此validation？ Spring MVC 3支持使用JSR-303 @Valid注释validation@Controller输入。 我们将约束置于何处进行validation？ 根据JSR-303，存储这些约束的最佳位置（@NotNull，@ Length等）属于业务实体本身。 底线：最好使用业务实体作为命令/表单对象。
- 关注点的分离仍然受到尊重。 这只是一个问题（forms支持）不再是一个问题！ Spring MVC为您处理它。 :-)你只需要担心你的业务实体。