wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes implementation strategy for a simple ordering application. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "implementation strategy for a simple ordering application." Watch "implementation strategy for a simple ordering application." New topic
Author

implementation strategy for a simple ordering application.

Yelle Cao
Greenhorn

Joined: Sep 13, 2011
Posts: 1
Hello all,

I'm quite new to EJB. Currently I'm working on a simple ordering application.
I wonder if someone can give me some advice on how to choose entity classes.
I've got business domain objects, such as Order, OrderItem, Shipping, Payment, Customer. Since Order object is related to all other objects, I'm thinking about modeling all these objects as entity beans. And in the Order class, I define one-to-many relationship with OrderItem, one-to-one relationship with Shipping and payment, and many-to-one relationship with Customer. There should separate tables to store keys for many-to-one and one-to-many relationships. So besides 5 tables for these 5 entity beans, I've got 2 additional tables called order_OrderItem and customer_order.

My questions are:
1. Is this a good decision to use these 7 tables to store the information for the 5 business objects? I checked similar implementation in Java EE tutorial, where order and OrderItem are modeled by 2 tables, where OrderItem table contains a compound primary key consisting of orderId and ItemId. Is it a better choice to use compound primary key?
2. Since in EJB3, entity bean can be used as POJO, is it a common practice to use EJB 3 entity beans in the presentation layer? For example, I need some session object called Order, should I define a different Order class which doesn't contain references to information such as payment, shipping? In the presentation layer, sometimes these objects don't have to have relationships. If I define a different class, they will look very similar and contain lots of duplicate information. If I use entity class, then it contains more information than needed, and it's not good to use terms from business tier in presentation tier. Or should I create a parent Order class and extended it with 2 child Order classes, one of which is used to create session objects and the other for entity objects? Can someone give advice on it?

Thanks.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: implementation strategy for a simple ordering application.