Kava Pava Gava Tava Nava Zava Java

everything about Java
随笔 - 15, 文章 - 0, 评论 - 1, 引用 - 0
数据加载中……

Java Type Conversion Framework

I need a simple framework that converts object from any type (class) to another, with registered converters and a unified interface. I though of writting one for myself but then want to study what has already been done.

Candidates

Refer to http://ezmorph.sourceforge.net/faq.html, the following are discussed
  • Commons-Convert will focus on Object->String->Object conversions
  • Commons-Lang's ArrayUtils only supports array conversions from primitive types to wrappers and back
  • Commons-Beanutils's ConvertUtils only supports conversions of String->Object
  • Lorentz - no longer active
  • Morph - seems fine, worth further investigation
  • Spring's PropertyEditors work very similar to ConvertUtils, from String->Object and Object->String.
  • Dozer - seems fine, worth further investigation
  • EZMorph - good "WHY" section, worth further investigation
Further study of Morph, EZMorph and Dozer

Framework
 EZMorph  Morph  Dozer
URL
 http://ezmorph.sourceforge.net/index.html
http://morph.sourceforge.net/index.html
 http://dozer.sourceforge.net/documentation/about.html
History 2006-2008
 2004-2008  2005-2009
Team
one man project
2 + 1 contributer
3 + many contributer
Statements

EZMorph's key strenghts are:

  • Supports transformations for primitives and Objects
  • Supports transformations for multidimensional arrays
  • Supports transformations with DynaBeans
  • JDK 1.3.1 compatible
  • Small memory footprint (~76K)

Morph is a Java framework that eases the internal interoperability of an application. As information flows through an application, it undergoes multiple transformations. Morph provides a standard way to implement these transformations. For example, when a user submits data using an HTML form in a J2EE application, the data typically goes through three transformations. First, HTTP request parameters are converted to presentation-tier command objects. Second, the command objects are converted into business objects. Finally, the business objects are persisted to a database.

In addition to providing a framework for performing transformations like those described above, Morph provides implementations of many common transformations, including all three of the transformations in the example above (1 and 2 are done now, 3 is partially done). As you can see, Morph is surprisingly powerful out-of-the-box, but it can't solve every problem. Instead, it provides a simple API you can use to harness its power for your particular situation. It has been built from the ground up for flexibility and extensibility, and integrates seamlessly with dependency injection frameworks such as Spring, PicoContainer and Hivemind.

Many of the ideas in Morph were inspired by the Apache Jakarta Commons BeanUtils project, the Apache Jakarta Commons sandbox component called Convert and the Context notion of the Apache Jakarta Commons Chain project. Morph synthesizes ideas from these various areas into one consistent API. Implementations are be provided that solve many common problems such as mapping HTTP request parameters to POJOs and converting a SQL statement into Java objects.

Dozer is a Java Bean to Java Bean mapper that recursively copies data from one object to another. Typically, these Java Beans will be of different complex types.

Dozer supports simple property mapping, complex type mapping, bi-directional mapping, implicit-explicit mapping, as well as recursive mapping. This includes mapping collection attributes that also need mapping at the element level.

Dozer not only supports mapping between attribute names, but also automatically converting between types. Most conversion scenarios are supported out of the box, but Dozer also allows you to specify custom conversions via XML.

The mapper is used any time you need to take one type of Java Bean and map it to another type of Java Bean. Most field mapping can be done automatically by Dozer using reflection, but any custom mapping can be predescribed in XML format. Mapping is bi-directional so only one relationship between classes needs defining. If any property names on both objects are the same you do not even need to do any explicit property mapping for these fields......

Runtime
Dependency
(optional: log4j)
14 packages, including some seemingly heavy ones...
commons-beanutils
commons-collections
commons-lang
commons-logging
Compile-time
Dependency
commons-lang
(optional: commons-beanutils, commons-logging, junit)
14 packages, including some seemingly heavy ones... same as above
My Observation
Seem to suit my needs
Too much dependency
Seem to be an overkill for my purpose

posted on 2010-01-27 14:49 bing 阅读(442) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航: