In Case Dozer Or BeanUtils Are Working Well You Have A Problem
Dozer is a great open source utility which is very good in copying Java Beans back and forth. Dozer heavily leverages the principle of "Convention over Configuration" (CoC) so it works best in case the objects you are copying are identical.
Similar functionality offers Apache's BeanUtils library.
For unknown reasons predominantly in "Enterprise" projects DTOs are used primarily to decouple the service user from the the service realization.
Dozer is often used to efficiently copy the data between JPA entities and DTOs. Automatic object synchronization works best in case both objects hierarchies are identical. Given Dozer's Convention Over Configuration nature each difference in the class structure requires configuration. The more the hierarchies diverge, the less efficient Dozer or BeanUtils becomes.
By keeping both hierarchies identical you have the least effort in copying …but also no decoupling. Both, JPA and DTOs, need to be manually synchronized, otherwise CoC-based frameworks will fail by copying the attributes. You could try to generate the DTOs from the JPA entities but this will result in even less decoupling.
In case Dozer is working well out-of-the-box without any configuration, you probably have to think about your design goals and decisions.
[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 273 in, chapter "Transfer Object and Data Transfer Object"]
See you at Java EE Workshops at MUC Airport!
Why not using JPA Entities as DTOs and using Dozer with a "CustomFieldMapper" for handling "lazy-loading" problems?
Posted by Chris on January 22, 2013 at 01:07 PM CET #
@Chris,
a good point.
But: you could equally well just invoke all getters. But then: it would work like eager-loading :-)
Please also see: http://www.adam-bien.com/roller/abien/entry/lazy_loading_entities_in_views
thanks,
adam
Posted by Adam Bien on January 22, 2013 at 01:26 PM CET #
We use it to clone objects. Like, we have this process definition, I want to use it as a base to build a new one. It doesn't need to be fast, but it does need to work. We do so with some custom transformer over bean lib so to not copy anything stupid. We also follow cascade options to guess when to reference or deep copy an entity. Then it's just a matter of zeroing id's with every entity involved in the process knows what to do by themselves (kind like a custom Cloneable interface). It seems a bit complex, but for large entity graphs its worth it
Posted by Solerman Kaplon on January 22, 2013 at 08:51 PM CET #
@Solerman,
it sounds like you are getting value out of Dozer by using its unique features. In case the reasons for maintaining parallel object hierarchies are obvious to an average developer--this is how it is supposed to be.
In some of my projects synchronization between object hierarchies was justified with "decoupling" without any further explanation...
thank you for the comment!,
adam
Posted by Adam Bien on January 23, 2013 at 07:00 AM CET #
Why use Dozer or BeanUtils at all?
The question asked here is quite relevant: do you need this "decoupling" at all? For a lot of usages, you simply don't.
If you really need to have a side hierarchy, just use the accessors to copy from an hierarchy to the other. If you don't, you are basically coupling them by names. A rename or change of functionality (removal of field, ...) will break that without noticing before run time.
It's some work at first to call getters/setters, but you'll have the benefit of letting the compiler check the basic things that shouldn't break.
I never saw any use of Dozer or BeanUtils that was justified.
Posted by Yannick Majoros on December 26, 2013 at 04:50 PM CET #
How about many dynamic SOAP Client proxies, were the contract may change within some boundries generating slightly different source objects containing nearly the same destination data, making it easy to add future interfaces using only configuration and not WSDL to Java (generate, build, deploy cycle)?
Posted by Maurice on May 05, 2014 at 04:31 PM CEST #
We use Dozer to create easily stripped down subsets of entities in cases you don't need all attributes, e.g. an order contains a list of items but for a quick overview you don't need all attributes of the items. The combination of (DSL) generated DTOs and Dozer does a good job here.
Are there better ways to do this?
Posted by Bruno on August 25, 2014 at 10:12 AM CEST #
In our project, we have a client who is invoking our EJBs remotely. The remote interface has some "DTO" parameters. Our DTOs are using Bean Validation annotations, and quite often the validations call business EJBs. This creates a cascading dependency chain: if we want to share our DTOs, we must share our annotations, so we must share the validation logic, so we must share the EJBs...
I think the way around this is to create new DTOs solely for use by the remote interface. Then we will use Apache BeanUtils to copy the properties to our internal objects.
I don't see a good way around this. We would face the same problem if we weren't using DTOs; i.e. if we were using detached JPA entities.
Perhaps we shouldn't have put "complex" validation logic in Bean Validators, but I don't see why not: there are significant benefits, including automatic framework (JPA, JSF) validation.
Posted by David on July 06, 2015 at 09:33 PM CEST #