• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
  • paul wheaton
  • Tim Cooke
  • Devaka Cooray
  • Rob Spoor
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin

implementation strategy for a simple ordering application.

Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

On top of spaghetti all covered in cheese, there was this tiny ad:
a bit of art, as a gift, the permaculture playing cards
    Bookmark Topic Watch Topic
  • New Topic