Hi all,

I have one question related to domain model design.

I have one entity Order, which has references to some master data entities like Currency and Country:

@Entity
@Table( name = "ORDERS" )
public class Order {

………………………………….

@Column ( name = "CURRENCY_ID" )
private Currency currency;

@Column ( name = "COUNTRY_ID" )
private Country country;
………………………………….

}

I have a service OrderService with a method to create new Order.

public class OrderService {

OrderDao orderDao;
CurrencyService currencyService;
CountryService countryService;


……………………

public void createOrder(Order order, String currencyId, String countryId) {
// load currency entity using some service
Currency currency = currencyService.getCurrency(currencyId);

// load country using some service
Country country = countryService.getCountry(countryId);

// set it to the order object
order.setCurrency(currency);
order.setCountry(country);

// now save order
orderDao.save(order);

}
……………………

}
What I don’t like in this approach is:
· OrderService.createOrder() method requires three parameters instead of one.
· Every time I create a new order I have to load objects currency and country for this order (I know I can create proxies for them using Session.load() or load them from cache).

The second variant is to use identifiers in Order class instead of entities for currency and country:

@Entity
@Table( name = "ORDERS" )
public class Order {

………………………………….

@Column ( name = "CURRENCY_ID" )
private String currencyId;

@Column ( name = "COUNTRY_ID" )
private String countryId;
………………………………….

}

The OrderService is in this case also simpler:


public class OrderService {

OrderDao orderDao;

……………………

public void createOrder(Order order) {

// now save order
orderDao.save(order);

}
……………………

}

The currencyId and countryId are set in this case on the client side and the Order is passed completely configured to the backend.

Currency and Country entities continue to exist in the application (they are needed in some other use cases), but are not used any more in the Order class.

What do you think about this second option compared to the first variant? Are there any pitfalls I don’t know about?

Thank you in advance.

The second approach is a bad design. As it does not represent the referential integrity in the db. It makes the db very prone to corruption.

If any of the currency or country gets deleted it will render the order object unusable.

Regards,
Jitendra

Thank you for the answer Jitendra.

But I'm afraid you are not right.

Because the fact that I'm using ids instead of entities in my Order class does not mean that the foreign keys are not there.

You can not delete country or currency, because there are Orders that reference it.

In this case I am assuming that you are putting the foreign key by using sql queries on db.

This will mean that there is a disparity between your table representation in code and db, which is not a really welcome approach.

Regards,
Jitendra

Yes Jitendra, you are right, foreign keys exist of course on the database level and were created at the same time the table were created using DML statements.

Only database can guarantee referential integrity, none of the mentioned two approches can guarantee it (at least i don't know how).

In both of my approaches I can pass to the OrderService currencyId or countryId which don't not exist in the database and build an invalid Order object. If I will try to save it, the exception will be thrown. In both of the approches.

I don't really understand, what you mean by disparity between my table representation in code and db. If you mean that I have ids in my code and the table references other tables, which are entities, I'm aware of it. It is not really object-oriented and may not be a welcome approach, but I would like to know what other problems it may cause in the future.

Because the fact that it is not object-oriented enough is not a good argument for me for the first approach.

Okay. I am kind of opposite in thinking. I like to go with standard thing until and unless I come across issues. In this case I would have chosen comfortable OO approach which is easier to explain and seek help if there are any issues in future.

You can refer to my discussion with one of the hibernate team members for someone following similar approach in code.

http://forum.hibernate.org/viewtopic.php?t=976143&highlight=

Regards,
Jitendra