This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
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 Android Security Essentials Live Lessons this week in the Android 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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: implementation strategy for a simple ordering application.
 
Similar Threads
Cleared Part I today with 79%
Handling relationships (between objects)
Entity Beans Many-Many relationship
Managing relationships (between objects)
CMR Questions