Spring formBackingObject、业务对象创建和工厂
在 Spring SimpleFormController 中使用业务对象作为 formBackingObjects 的设计问题。
我们的控制器的职责是允许最终用户向我们的 Web 应用程序添加新的业务对象。
因此，我们通过 formBackingObject(HttpServletRequest request) 方法传递业务对象。然而，我们遇到了一个难题。
我们用来创建新业务对象的工厂强制执行某些属性不能为空的业务规则。但由于我们不知道最终用户想要输入什么，所以我们一直在传递“合理的默认值”，例如“请输入您想要的名称”，但这充其量似乎是 hackie/icky。
开发商要做什么？我觉得这是典型的先有鸡还是先有蛋的问题。
我们所有的业务对象都基于接口，我们是否应该创建一个代表业务对象的存根，将存根作为 formBackingObject 传递，然后在表单提交上将存根传递给工厂？或者我们不应该在 formBackingObject 中传递任何内容，然后手动从请求中收集提交的信息？
还有其他合理的想法/模式吗？
感谢您抽出时间。
Design question for using Business Objects as formBackingObjects in a Spring SimpleFormController.
Our controller's responsibility is to allow an End User to add a new Business Object to our web application.
So we are passing our Business Object though the formBackingObject(HttpServletRequest request) method. However, we've run into a conundrum.
The factory that we are using to create our new Business Object enforces the business rules that some of the attributes cannot be null. But since we don't know what the End User wants to enter we've been passing in "reasonable defaults" like "Please enter the name you want", but that seems hackie/icky at best.
What is a developer to do? I feel as though this is the classic chicken/egg problem.
All our Business Object are based off of Interfaces, should we create a Stub that represents the Business Object, pass the Stub as the formBackingObject, and then pass the Stub to the Factory on a Form submit? Or should we not pass anything in the formBackingObject and then manually gather the submitted information from the request?
Any other reasonable ideas/patterns?
Thank you for your time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我绝对不会选择不使用 formBackingObject 并手动收集信息的选项——这会消除 Spring MVC 最初的价值所在。
如果我是您，我只会创建一个新工厂或工厂方法，专门设计用于创建“未初始化”业务对象，并将其用作您的 formBackingObject。
另一种广泛使用的方法是根本不使用业务对象作为 formBackingObject，而是创建一个单独的传输对象，其唯一目的是作为 formBackingObject（然后为业务对象添加一个工厂方法，让您可以从运输对象）。这样做的一大优点是，如果您的业务对象内部有一个由其他对象组成的深层树，那么用作 formBackingObject 会变得很痛苦。如果您创建一个单独的传输对象仅用作 formBackingObject，则可以为其提供更扁平的结构。
I definitely wouldn't choose the option of not using a formBackingObject and gathering the information manually -- that would eliminate a lot of the power that makes Spring MVC worthwhile in the first place.
If I were you, I would just make a new factory, or factory method, that is designed specifically to create an "uninitialized" business object, and use that as your formBackingObject.
Another approach that is widely used is not to use a business object as your formBackingObject at all, but create a separate transport object whose only purpose is to be the formBackingObject (and then add a factory method for your business object that lets you initialize it from the transport object). One of the big advantages of this is if your business object has a deep tree of other objects inside it, this can make it a pain to use as a formBackingObject. If you create a separate transport object just for use as a formBackingObject, you can give it a much flatter structure.
使用命令对象（一个非常简单的 POJO）来表示用户对控制器的输入。然后，您可以使用 Spring MVC 内置的验证来确保命令对象中提供了所有必需的字段。如果命令通过验证，那么您可以以编程方式将其映射到您的“业务对象”（或使用 bean 映射库，如 推土机）。
通过这种方式，您可以处理验证、不完整的用户提交等，而无需触及或修改任何现有的业务逻辑/规则/服务类。这允许您将 web 图层与这些现有图层分开。
有关参考，请参阅MVC 教程，其中涉及第 4 部分中的验证和命令对象。
Use a command object (a dead simple POJO) to represent the user's input to your controller. Then you can use the validation built-in to Spring MVC to make sure that all of the required fields are supplied in the command object. If the command passes validation, then you can map it to a your "Business Object" programatically (or using a bean mapping library like Dozer).
This way you can handle validation, incomplete user submissions, etc., without touching or modifying any existing business logic / rules / service classes. This allows you to keep the web layer separate from these existing layers.
For reference, see the MVC tutorial, which touches on validation and command objects in Part 4.