DTO and mapper generation from Domain Objects [closed]
Asked Answered
H

5

16

I have plenty of java domain objects that I need to transform to DTOs.

Please, don't start with the anti-pattern thing, the Domain Objects are what they are because of a long history, and I can't modify them (or not too much, see below).

So, of course, we've passed the age of doing all that manually. I've looked around, and dozer seems the framework of choice for DTO mapping.

But... what I'd really like is this: annotate classes and fields that I want in DTO, and run a tool that would generate the DTOs and the mappers.

Does that sound too unreasonable?

Does such a tool already exist?

Hackworth answered 13/5, 2010 at 16:13 Comment(5)
Possibly, but it might help to get an idea which language you're referring to. Java/.Net?Shutin
Yes... sorry... I realized after asking the question. I've updated it.Hackworth
Dozer is a horrible, slow, black box, hard to debug, hard to maintain all kinds of problems mapping collections, updating objects in place with any kind of complex relationship, difficult to customize....ugh. Better to write your mapping by hand: fast, debuggable, refactorable via IDE. My 2¢Ceciliacecilio
@NicolasC: did you finally find a tool and if yes, which did you use? It seems like none of the answers actually answers the need to generate DTOs ("I have plenty of java domain objects that I need to transform to DTOs."), which is exactly the need that I have now. The answers all seem to assume that the DTOs already exist.Lysozyme
Possible duplicate of any tool for java object to object mapping?Amplexicaul
A
13

Consider checking out my ModelMapper.

It differs from Dozer and others in that it minimizes the amount of configuration needed by intelligently mapping object models. Where configuration is needed, ModelMapper offers a refactoring safe API that uses actual code to map properties and values rather than using string references or XML.

Check out the ModelMapper site for more info:

http://modelmapper.org

Arellano answered 24/6, 2011 at 6:11 Comment(1)
Doesn't ModelMapper only generate mappers but not DTOs?Magnetism
M
8

You might be interested in MapStruct, a code generator for JavaBeans mappers. You'd have to implement source model (e.g. your domain objects) and target model (e.g. DTOs), and MapStruct generates type-safe and fast code for mapping between these models (disclaimer: I'm the author of this project).

Midvictorian answered 11/8, 2013 at 12:34 Comment(0)
K
3

This thread is a bit old, but if anyone is is still trying to do this, http://www.dtonator.org/ is the best option I have found so far. It is the only tool I have been able to find that actually CREATES the DTO files and isn't tied to a specific framework (Spring, Seam, etc.) or IDE.

Kosey answered 1/9, 2017 at 14:17 Comment(0)
L
2

Use GeDA - much faster and more flexible than all of the mentioned mappers. http://inspire-software.com/confluence/display/GeDA/GeDA+-+Generic+DTO+Assembler

There aren't many examples on the wiki but the junits (in source) are full of them

Lymphangial answered 6/2, 2013 at 0:31 Comment(0)
W
1

Mybe late, I develop an annotation processor called beanknife recently, it support generate DTO from any class. You need config by annotation. But you don't need change the original class. This library support configuring on a separate class. Of course you can choose which property you want and which you not need. And you can add new property by the static method in the config class. The most power feature of this library is it support automatically convert a object property to the DTO version. for example

class Pojo1 {
    String a;
    Pojo b;
}

class Pojo2 {
    Pojo1 a;
    List<Pojo1> b;
    Map<List<Pojo1>>[] c;
}

@ViewOf(value = Pojo1.class, includePattern = ".*", excludes={Pojo1Meta.b})
class ConfigureOfPojo2 {}

@ViewOf(value = Pojo2.class, includePattern = ".*")
class ConfigureOfPojo2 {
    // convert b to dto version
    @OverrideViewProperty(Pojo2Meta.b)
    private List<Pojo1View> b;
    // convert c to dto version
    @OverrideViewProperty(Pojo2Meta.c)
    private Map<List<Pojo1View>>[] c;
}

will generate

// meta class, you can use it to reference the property name in a safe way.
class Pojo1Meta {
    public final String a = "a";
    public final String b = "b";
}

// generated DTO class. The actual one will be more complicate, there are many other method.
class Pojo1View {
    private String a;
    public Pojo1View read(Pojo1 source) { ... }
    ... getters and setters ...
}

class Pojo2Meta {
    public final String a = "a";
    public final String b = "b";
    public final String c = "c";
}

class Pojo2View {
    private String a;
    private List<Pojo1View> b;
    private Map<List<Pojo1View>>[] c;
    public Pojo1View read(Pojo2 source) { ... }
    ... getters and setters ...
}

The interest things here is you can safely use the class not exist yet in the source. Although the compiler may complain, all will be ok after compiled. Because all the extra class will be automatically generated just before compiled. A better approach may be to compile step by step, first add @ViewOf annotations, and then compile, so that all the classes that need to be used later are generated. Compile again after the configuration is complete. The advantage of this is that the IDE will not have grammatical error prompts, and can make better use of the IDE's auto-complete function.

Worldling answered 25/12, 2020 at 18:55 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.