2

I need to store domain object (DO) into DB.

The simplest approach is to add into DO definition some JPA annotations like @Entity, @SequenceGenerator, @Table etc. but I don't want to mix DO with another conception like persisting. So I use separate DTO object and put annotations here.

As I'm a great Domain Driven Design follower I don't interconnect with DB directly and use Repository pattern. If in the future I migrate from RDBMS to e.g. NoSQL all changes will be done only in Repository and my DO will be intact.

Thus the flow sequence is

DO -> Repository -converting-> DTO -> DB

As my DO has a lot of fields the conversion step is quite cumbersome and at the same time quite trivial: get fieldA from DO and put it into fieldA' in DTO (with simple transformations in some cases). Currently I do this manually in a separate Transformer.

What are other (better?) approaches to do this conversion step?

UPDATE

Good comparison of bean mapping frameworks Dozer vs Orika vs Manual field mapping approach

Andriy Kryvtsun
  • 3,220
  • 3
  • 27
  • 41
  • 2
    Seems like overengineering. – Everv0id Apr 15 '16 at 22:16
  • @Everv0id can you propose better approach? – Andriy Kryvtsun Apr 15 '16 at 23:37
  • IT seems what orm mappers arefor unless there is something in you db that warrants the dto object. But then you won't have 1-1 mapping anymore (and you can always redesign then needed. YAGNI applies here too) – Batavia Apr 17 '16 at 08:31
  • Isn't there some kind of fluent off-entity mapping in the Java world ? Not that Hibernate XML files were a joy to work with, but at least you didn't have to redeclare and map a whole additional layer of DTOs to remain persistence agnostic. – guillaume31 Apr 18 '16 at 15:33
  • There is Blaze-Persistence Entity Views(https://github.com/Blazebit/blaze-persistence#entity-view-usage) which is a library allowing to create DTOs based on JPA entities with ease, but I don't understand why you need a distinction between DO and DTO. Why can't your DTOs simply be your DOs? – Christian Beikov Jul 19 '18 at 09:50

2 Answers2

4

First of all, that's quite a great idea to separate your persistent entity from your domain objects. I used to deal with setups where both approaches have been mixed together and that lead us to a complete mess afterwards.

The approach you're looking for is called 'Bean mapping'. There are a lot of such mappers around, Dozer seems to be the most widely used, but it's reflection-based and thus it's quite slow. Orika has good balance between performance and extensibility, but it also leads to some weird classloading issues in Java EE environment.

Most of bean mappers perform automatic mapping for equally named fields, extra conversions may be defined for 'simple transformations' you have mentioned above. Here's the example of Orika configuration for particular Web-to-DB entity mapping (with workaround for the classloading issue mentioned above applied): https://bitbucket.org/__jtalk/jacra/src/default/JAcraEJB/src/main/java/me/jtalk/jacra/utils/mapper/MappersRegistration.java

You can then use those mappers like:

@Inject
@UserMapper
private BoundMapperFacade<UserEntity, UserWeb> userMapper;
...
UserEntity entity = userMapper.mapReverse(userWeb);
mapper.map(entity);
Roman Nazarenko
  • 608
  • 4
  • 11
1

Instead of annotations, if you really will want to move to NoSQL in the future you can use yaml, xml mapping.

DO -> Repository -converting-> DTO -> DB
What are you trying to do here is simply copy the function of ORM. It will take much more time, probably creates new bugs and is not worth of it at all.

You can successfully, use ORM for entites. They will not make you couple with the framework, because framework will operate on higher level of abstraction.
Repository is an interface, so you can create NoSqlRepository in the future and your application will just works fine. (Not counting the data migration)

Dariss
  • 1,258
  • 1
  • 12
  • 27