Spring formBackingObject、业务对象创建和工厂答案

【问题标题】：Spring formBackingObject, Business Object Creation, and FactoriesSpring formBackingObject、业务对象创建和工厂
【发布时间】：2009-11-11 18:02:27
【问题描述】：

在 Spring SimpleFormController 中使用业务对象作为 formBackingObjects 的设计问题。

我们的控制器的职责是允许最终用户向我们的 Web 应用程序添加新的业务对象。

所以我们通过 formBackingObject(HttpServletRequest request) 方法传递我们的业务对象。然而，我们遇到了一个难题。

我们用来创建新业务对象的工厂强制执行某些属性不能为空的业务规则。但是由于我们不知道最终用户想要输入什么，我们一直在传递“合理的默认值”，例如“请输入您想要的名称”，但这似乎充其量是 hackie/icky。

开发人员要做什么？我觉得这好像是经典的鸡/蛋问题。

我们所有的业务对象都是基于接口的，我们是否应该创建一个代表业务对象的存根，将存根作为 formBackingObject 传递，然后在表单提交时将存根传递给工厂？或者我们不应该在 formBackingObject 中传递任何东西，然后从请求中手动收集提交的信息？

还有其他合理的想法/模式吗？

感谢您的宝贵时间。

【问题讨论】：

看看这个讨论：stackoverflow.com/questions/378066/…

标签： java spring factory-pattern

【解决方案1】：

我绝对不会选择不使用 formBackingObject 并手动收集信息的选项——这会首先消除使 Spring MVC 有价值的许多功能。

如果我是你，我会创建一个新工厂或工厂方法，专门用于创建“未初始化”业务对象，并将其用作您的 formBackingObject。

另一种广泛使用的方法是根本不使用业务对象作为您的 formBackingObject，而是创建一个单独的传输对象，其唯一目的是作为 formBackingObject（然后为您的业务对象添加一个工厂方法，让您从传输对象初始化它）。这样做的一大优点是，如果您的业务对象内部有其他对象的深层树，那么将其用作 formBackingObject 会很痛苦。如果您创建一个单独的传输对象仅用作 formBackingObject，则可以为其提供更扁平的结构。

【讨论】：

所以，我非常赞同使用未初始化的业务对象或使用传输对象的想法，但是如何使用传输对象或简单的 POJO（来自 matt b 的帖子）与在struts 中使用ActionForm 有何不同？在某些时候，我们将不得不从传输/POJO 中提取信息并将其放入基于休眠的业务对象实现类中。我问的唯一原因是因为我记得这是春天的主要卖点。我很欣赏不必扩展 ActionForm，但结果和行为对我来说似乎是一样的。
这是一个公平的观点。出于这个原因，我自己更喜欢将业务对象用作 formBackingObject。另一方面，将数据从一个对象移动到另一个对象的代码并不那么复杂。这种方法可能有意义的一个地方是，如果您有一个复杂的业务对象，其中每个表单只填充它的一部分。

【解决方案2】：

使用命令对象（一个非常简单的 POJO）来表示用户对控制器的输入。然后，您可以使用 Spring MVC 内置的验证来确保在命令对象中提供了所有必需的字段。如果命令通过验证，那么您可以通过编程方式将其映射到您的“业务对象”（或使用像 Dozer 这样的 bean 映射库）。

这样您就可以处理验证、不完整的用户提交等，而无需触及或修改任何现有的业务逻辑/规则/服务类。这允许您将 Web 层与这些现有层分开。

有关参考，请参阅the MVC tutorial，其中涉及Part 4 中的验证和命令对象。

【讨论】：