Spring formBackingObject，业务对象创建和工厂
在Spring SimpleFormController中使用Business Objects作为formBackingObjects的设计问题。
我们的控制器的职责是允许最终用户向我们的Web应用程序添加新的业务对象。
所以我们通过formBackingObject（HttpServletRequest请求）方法传递我们的业务对象。 但是，我们遇到了一个难题。
我们用于创建新业务对象的工厂强制执行某些属性不能为null的业务规则。 但是因为我们不知道最终用户想要输入什么，所以我们一直在传递“合理的默认值”，例如“请输入你想要的名字”，但这似乎充满了hackie / icky。
什么是开发人员？ 我觉得这是经典的鸡/蛋问题。
我们所有的业务对象都基于接口，我们是否应该创建一个代表业务对象的存根，将存根作为formBackingObject传递，然后将Stub传递给工厂提交表单？ 或者我们不应该在formBackingObject中传递任何内容，然后手动从请求中收集提交的信息？
还有其他合理的想法/模式吗？
感谢您的时间。
我绝对不会选择不使用formBackingObject并手动收集信息 – 这将消除使Spring MVC首先值得的大量function。
如果我是你，我会创建一个专门用于创建“未初始化”业务对象的新工厂或工厂方法，并将其用作formBackingObject。
另一种广泛使用的方法是根本不使用业务对象作为formBackingObject，而是创建一个单独的传输对象，其唯一目的是成为formBackingObject（然后为业务对象添加一个工厂方法，允许您从运输对象）。 这样做的一个重要优点是，如果您的业务对象中包含其他对象的深层树，这可能会使用它作为formBackingObject变得很麻烦。 如果创建一个单独的传输对象只是用作formBackingObject，则可以为其提供更平坦的结构。
使用命令对象（一个简单的简单POJO）来表示用户对控制器的输入。 然后，您可以使用Spring MVC内置的validation来确保在命令对象中提供所有必需的字段。 如果命令通过validation，那么您可以以编程方式将其映射到“业务对象”（或使用像Dozer这样的bean映射库）。
这样，您可以处理validation，不完整的用户提交等，而无需触及或修改任何现有的业务逻辑/规则/服务类。 这允许您将Web图层与这些现有图层分开。
有关参考，请参阅MVC教程 ，该教程涉及第4部分中的validation和命令对象。