Spring中的PropertyEditor、Formatter和Converter有什么区别？

发布于 2025-01-15 00:56:59 字数 728 浏览 0 评论 0 原文

使用 Spring MVC 事实证明，我可以通过多种不同的方式绑定我的表单，但我真的感觉自己迷失了方向。 Formatter 的 parse 和 print 方法相当于具有不同名称的 PropertyEditorSupport 的方法（ >getAsText 和 setAsText）。同样，我可以实现一个 GenericConverter 或两个 Converter 来完成完全相同的操作。

我在此处的评论中读到Formatters 是 PropertyEditor 的替代品，但我还没有找到任何支持它的文档，而且它甚至还没有被弃用。

我的问题是，当涉及到将数据从表单绑定到对象时，在 spring-mvc 中正确的方法是什么？ Spring中的PropertyEditor、Formatter和Converter之间的主要区别是什么？每一种的用例是什么？对我来说，他们似乎负有同样的责任。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

蓝色星空 2025-01-22 00:56:59

为了帮助理解这些概念，我首先将 Spring 特定功能与 Java 公开的功能区分开来。

PropertyEditor 和相关内容由JavaBeans 规范定义。

该规范定义了用于处理对象、对象属性以及与其更改相关的所有内容（作为事件）的 API、机制和约定。

PropertyEditor 通常在 GUI 中用于处理 UI 和底层对象模型之间的交互，通常处理属性值与其 String 表示形式之间的转换。

Spring 本身实际上在许多不同的情况下使用不同的 PropertyEditor 实现和 Java Beans 约定。例如，来自 docs< /a>:

在 Spring 中使用属性编辑的几个示例：

通过使用 PropertyEditor 设置 Bean 的属性
实施。当您使用 String 作为某些属性的值时
您在 XML 文件 Spring 中声明的 bean（如果
相应的属性有一个 Class 参数）使用 ClassEditor 来尝试
将参数解析为 Class 对象。

在 Spring 的 MVC 框架中解析 HTTP 请求参数是通过
使用您可以手动执行的各种 PropertyEditor 实现
绑定到 CommandController 的所有子类中。

总之，PropertyEditor 允许您实现更广泛的用例。

现在，在 Spring 世界中，您还需要区分 Spring MVC 和 Spring Core。

请注意，转换和 Formatter 的东西是被定义为核心技术，与任何用例相关，但不限于网络框架。

Spring 文档，在描述 Spring 字段格式，对每个 API/SPI 的用途以及它们与 PropertyEditor 的关系提供了很好的解释：

如上一节所述，core.convert 是一个通用目的
类型转换系统。它提供了一个统一的 ConversionService API 作为
以及用于实现转换逻辑的强类型转换器 SPI
从一种类型到另一种类型。 Spring容器使用这个系统来绑定bean
属性值。此外，Spring 表达式语言 (SpEL)
DataBinder 使用该系统来绑定字段值。例如，当
SpEL 需要将 Short 强制转换为 Long 来完成
expression.setValue(Object bean, Object value) 尝试，core.convert
系统执行强制。

现在考虑典型客户端的类型转换要求
环境，例如 Web 或桌面应用程序。在这样的环境下，
您通常从 String 进行转换以支持客户端回发过程，
以及返回String来支持视图渲染过程。在
此外，您经常需要本地化 String 值。比较一般的
core.convert Converter SPI 不满足此类格式要求
直接地。为了直接解决这些问题，Spring 3 引入了一个方便的
格式化程序 SPI 提供了一种简单而强大的替代方案
客户端环境的 PropertyEditor 实现。

一般情况下，需要实现时可以使用Converter SPI
通用类型转换逻辑——例如，用于在
一个java.util.Date和一个Long。当您
工作在客户端环境（例如Web应用程序）并且需要解析
并打印本地化的字段值。 ConversionService 提供了
两个 SPI 的统一类型转换 API。

在 Spring MVC 的特定用例中，框架本身能够处理简单类型，当处理 HTTP 请求。

类型转换是根据配置的转换器集自动应用，尽管可以使用 DataBinders 和前面提到的格式化系统。请参阅相关文档< /a>.

在处理读取和写入 HTTP 请求和响应正文的典型用例中，当使用 @RequestBody，例如Spring会使用一堆不同的预已配置 HttpMessageConverter< /a> 实现：实际注册的库将取决于您的配置和项目中导入的库 - 例如杰克逊。我无法在文档中找到这一点，但这里是实际源代码。

请考虑查看这个相关的SO问题，它可能是的帮助。

To help to understand these concepts I would differentiate first the Spring specific functionality from that exposed from Java.

PropertyEditors and the related stuff are defined by the JavaBeans Specification.

The specification defines an API, mechanisms and conventions for dealing with objects, objects properties, and everything related to their changes, as events.

PropertyEditors are typically used in GUIs to handle the interaction between an UI and the underlying objects model, typically handling the conversion between properties values from/to its String representation.

Spring itself actually uses different PropertyEditor implementations and Java Beans conventions in many different situations. For example, from the docs:

A couple of examples where property editing is used in Spring:

Setting properties on beans is done by using PropertyEditor
implementations. When you use String as the value of a property of some
bean that you declare in an XML file, Spring (if the setter of the
corresponding property has a Class parameter) uses ClassEditor to try
to resolve the parameter to a Class object.

Parsing HTTP request parameters in Spring’s MVC framework is done by
using all kinds of PropertyEditor implementations that you can manually
bind in all subclasses of the CommandController.

In summary, PropertyEditors allow you for a broader number of use cases.

Now, in the Spring world you need to do a differentiation as well between Spring MVC and Spring Core.

Please, note that both the Convert and the Formatter stuff are defined as core technologies, of relevance to any use case and not limited to the web framework.

The Spring documentation, when describing Spring Field Formatting, provides a great explanation about the purpose of every API/SPI and how they are related to PropertyEditors as well:

As discussed in the previous section, core.convert is a general-purpose
type conversion system. It provides a unified ConversionService API as
well as a strongly typed Converter SPI for implementing conversion logic
from one type to another. A Spring container uses this system to bind bean
property values. In addition, both the Spring Expression Language (SpEL)
and DataBinder use this system to bind field values. For example, when
SpEL needs to coerce a Short to a Long to complete an
expression.setValue(Object bean, Object value) attempt, the core.convert
system performs the coercion.

Now consider the type conversion requirements of a typical client
environment, such as a web or desktop application. In such environments,
you typically convert from String to support the client postback process,
as well as back to String to support the view rendering process. In
addition, you often need to localize String values. The more general
core.convert Converter SPI does not address such formatting requirements
directly. To directly address them, Spring 3 introduced a convenient
Formatter SPI that provides a simple and robust alternative to
PropertyEditor implementations for client environments.

In general, you can use the Converter SPI when you need to implement
general-purpose type conversion logic — for example, for converting between
a java.util.Date and a Long. You can use the Formatter SPI when you
work in a client environment (such as a web application) and need to parse
and print localized field values. The ConversionService provides a
unified type conversion API for both SPIs.

In the specific use case of Spring MVC the framework itself is able to handle simple types when handling the HTTP requests.

Type conversion is automatically applied based on the configured set of converters, although that behavior can be tweaked using DataBinders and the aforementioned Formatting system. Please, see the relevant docs.

In a typical use case in which you deal with reading and writing the body of HTTP requests and responses, when using the @RequestBody, for example, Spring will use a bunch of different pre-configured HttpMessageConverter implementations: the actual ones registered will depend on your configuration and the libraries imported in your project - say Jackson, for example. I was unable to find that point in the documentation but here is the link to the actual source code.

Please, consider review this related SO question, it could be of help.

回复收藏 0 原文

~没有更多了~