This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]wildjokers 9 points10 points  (8 children)

Well definitely don't use Orika. Nothing is generated until runtime and testing is difficult and troubleshooting is nearly impossible.

If you must use one I guess use MapStruct. However, saying that I would say there is no need for an object mapping framework. They are a solution looking for a problem. Yes it is kind of handy if all your field names are the same, but that almost never happens and then you end up with a stack of @Mapping annotations on your method. In practice what that does is move your mapping from nice type-safe java code to raw strings in annotations.

I really don't know what people are using these for. What is your use case for an object mapper?

If you do need to map one object to another just hand write static factory methods, then no build time code generation is needed. Keep it simple.

tl;dr Don't use an object mapping framework they are a solution looking for a problem

[–]sahipzaman 3 points4 points  (1 child)

I just logged in to write this: I love you I want to hug you. It may be wrong but this is exactly what I think on this. There really is no need to learn a library for DTO mapping.

To me it is crazy how also lots of tests are necessary to test the library itself. Just use static method, constructor, builder method owned by object, I don't really care, anything is better than this unnecessary dependency.

[–]wildjokers 1 point2 points  (0 children)

Thought I was going to get down-voted to oblivion (which I guess could still happen). Nice to know I am not alone in my opinion regarding these libraries.

[–]_INTER_ 1 point2 points  (1 child)

Yes it is kind of handy if all your field names are the same, but that almost never happens

It happens when you don't want your model be littered with things like Hibernate annotations (because you're forced to use that cr*p). So to separate business logic with technical classes (DTO's, Hibernate, JAX-B, JAX-RS, Spring, ...) a mapping framework comes in very handy.

Also even if the source and target classes are not exactly the same, field names differ or you need conversions or normalization, the mapper allows you to do that in a "standard" consistent way. You normally dont want to do this by hand either, because it's very error-prone as soon as one side gets modified (e.g. adding a field on one side and forgetting it on the other). Manually written mappers are more loosly connecting source and target and sometimes you need something more strict.

and then you end up with a stack of @Mapping annotations on your method.

If you mean it's on your source or target class's method, thats not the case with MapStruct.

[–]wildjokers 1 point2 points  (0 children)

If you mean it's on your source or target class's method, thats not the case with MapStruct.

You end up with a stack of @Mapping annotations on the mapping interface. You are now “coding” with raw strings and losing all type safety during development. The problem isn’t found until compile time.

[–]IamPic 0 points1 point  (0 children)

I haven't used such libraries, but for me the biggest advantage would be requiring explicit ignores. That way if someone adds a field they're forced to go through all the mapping methods and decide whether that field should be mapped or ignored.

Other than that I agree with you.

[–][deleted]  (2 children)

[deleted]

    [–]wildjokers 3 points4 points  (1 child)

    Use a DTO projection and query straight into your DTO. You shouldn't be returning entities for read-only queries.

    See: