This week's book giveaway is in the Server-Side JavaScript and NodeJS forum.
We're giving away four copies of Micro Frontends in Action and have Michael Geers on-line!
See this thread for details.
Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

implementation strategy for a simple ordering application.

Posts: 1
  • Mark post as helpful
  • send pies
  • 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?

Seriously? That's what you're going with? I prefer this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic