Return to Answer

In complex projects, it is always a good idea to use domain objects and DTOs. If you use your entities in other layers of your applications, you may sooner-or-later notice problems. And if you are already using them in your whole app, it is difficult to change is afterwards.

• other layers, which are not related to persistence, need to have a dependency on Hibernate
• if you use any other persistence technology, like NoSQL DB, you have to convert them anyway using some Translator. Hibernate and relational databases are just one possibility.
• contraints like NotNull may be OK for your DB, but are you sure it cannot be null in the UI?
• in other layers, you probably will not need all fields, so you do not need to transfer them to them.

So IMO it is a good idea to translate your objects between the layers. It can be tedious to build parallel objects for each layer, I think it is worth it. Dozer (not intended as spam) is a framework which may help to reduce that (although I have not used it yet).

Converters should just convert, not starting transactions (like in convertItem()). You could structure your application using DAOs, repositories and services. See DAO, Repositories and Services in DDD. Code like (Item)session.get(Item.class, itemDto.getItemId()) would probably be in a DAO, in an getById(long id)-method. Transactions are usually started on the service layer, using declarative transactions like in Java EE or Spring, you don't have to handle transactions manually.

A Service could have a simple method addItemToStore(). You could also introduce still a layer between the service and the DAO, but it is a good start for a simple service.

@Transactional
public void addItemToStore(Store store, Item item) {
 StoreEntity storeEntity = storeDao.getById(store.getId());
 ItemEntity itemEntity = itemDao.getById(item.getId());
 storeEntity.getItems().add(itemEntity);
 storeDao.save(storeEntity);
}

In complex projects, it is always a good idea to use domain objects and DTOs. If you use your entities in other layers of your applications, you may sooner-or-later notice problems. And if you are already using them in your whole app, it is difficult to change is afterwards.

• other layers, which are not related to persistence, need to have a dependency on Hibernate
• if you use any other persistence technology, like NoSQL DB, you have to convert them anyway using some Translator. Hibernate and relational databases are just one possibility.
• contraints like NotNull may be OK for your DB, but are you sure it cannot be null in the UI?
• in other layers, you probably will not need all fields, so you do not need to transfer them to them.

So IMO it is a good idea to translate your objects between the layers. It can be tedious to build parallel objects for each layer, I think it is worth it. Dozer (not intended as spam) is a framework which may help to reduce that (although I have not used it yet).

Converters should just convert, not starting transactions (like in convertItem()). You could structure your application using DAOs, repositories and services. See DAO, Repositories and Services in DDD. Code like (Item)session.get(Item.class, itemDto.getItemId()) would probably be in a DAO, in an getById(long id)-method. Transactions are usually started on the service layer, using declarative transactions like in Java EE or Spring, you don't have to handle transactions manually.

A Service could have a simple method addItemToStore(). You could also introduce still a layer between the service and the DAO, but it is a good start for a simple service.

@Transactional
public void addItemToStore(Store store, Item item) {
 StoreEntity storeEntity = storeDao.getById(store.getId());
 ItemEntity itemEntity = itemDao.getById(item.getId());
 storeEntity.getItems().add(itemEntity);
 storeDao.save(storeEntity);
}