• 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 ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

J2EE Bad Practice?

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, as many of you have already done in the past, I am putting together my first real J2EE application. I read more then a few articles and books and decided to use a session facade to implement the application. Then, last night, I pick up my copy of Core J2EE Patterns Best Practices and Design Strategies. On page 63 it states that mapping a relational model directly to an entity model is a bad practice.
Amoung the reasons:
It affects scalability.
It implements inter table relationships as entity bean to entity bean relationships.
So, this bothers me just a tad. Many of the tools I have tried, including Websphere Studio and Oracle's JDev have bottom up generators, that start you off in this very situation. Not to mention that the EJB 2.0 spec provides the CMR fields to help manage the entity bean to entity bean relationships.
Now, my particluar application will not be deployed across multiple servers and all beans will use local and not remote interfaces. So this may be where this particular pattern is ok, but I have not read anything to suggest that.
I have a feeling that I am going to spend the next several months developing this application that will end up running like a dog because I used too manny beans. I must be taking something out of context or something else has changed since this core book was printed. Trying to consume and manage all of this different information is a daunting task in itself, without having to deal with seemingly contradictory statements.
So, I came here to my trusted friends at the JavaRanch to help set this straight in my head and let me sleep at night. Any comments, suggestions or discussions is greatly appreciated.
Z
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't worry about it. With the capabilities of EJB 2.0 you should be fine with having your table model and your entity model be the same. Just be sure to take advantage of all the performance enhancements provided by your container, such as preloading of relationships, caching, etc.
Kyle
 
Travis Zimmerman
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the quick response, I didn't expect there to be one so quickly. it is a holiday! What are you doing paying attention to these forums?
I was not planning to use the CMR capabilities, it seemed like something a little too complicated to get into on my first go at this. What performance enhancements do they provide? Maybe I should read more into them to find this out for myself.
I read your article on the session facade, it was great by the way. The question I came across was in the factory. If you can not guarantee a singleton, how are you able to cache home references in the object? I was thinking about doing something similar, but more generic in that given the jndi name it would return the base EJBHome interface, that would then be cast to the appropriate type. The reason for this is that the session bean will interact with several entity beans. Instead of setting the value object in the factory, I was going to pass each local interface, in turn, to the value object to set it's state. But, the again I will be passing the value object back to the web tier, so maybe that isn't such a great idea.
Thanks again for the help,
Z
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Travis Zimmerman:
Thanks for the quick response, I didn't expect there to be one so quickly. it is a holiday! What are you doing paying attention to these forums?


My son is playing in his playroom and my wife is asleep. The cinnamon rolls I just made are in the oven and I've already checked my email and read the morning paper, so what else am I supposed to do?


I was not planning to use the CMR capabilities, it seemed like something a little too complicated to get into on my first go at this. What performance enhancements do they provide? Maybe I should read more into them to find this out for myself.


I would look into them if I were you. Almost all data models have inter-table relationships. Representing these as CMR's is the way to go -- for
instance, WebSphere has a "preload" optimization that allows you to load both ends of a relationship in a single SQL JOIN Statement when you run a finder method. This drastically cuts down the number of SQL statements executed and improves performance


I read your article on the session facade, it was great by the way. The question I came across was in the factory. If you can not guarantee a singleton, how are you able to cache home references in the object? I was thinking about doing something similar, but more generic in that given the jndi name it would return the base EJBHome interface, that would then be cast to the appropriate type. The reason for this is that the session bean will interact with several entity beans. Instead of setting the value object in the factory, I was going to pass each local interface, in turn, to the value object to set it's state. But, the again I will be passing the value object back to the web tier, so maybe that isn't such a great idea.
Thanks again for the help,
Z


Glad to be of service -- as for doing things in the value object rather than the factory -- the reason I prefer doing it in the factory is it's cleaner. That way the local EJB types are never actually exported outside the EJB JAR file. Only the Value object types and the Session bean types are visible outside that JAR file.
Kyle
[ November 27, 2003: Message edited by: Kyle Brown ]
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My son is playing in his playroom and my wife is asleep. The cinnamon rolls I just made are in the oven and I've already checked my email and read the morning paper, so what else am I supposed to do?


I have heard that people go on travel. Sorry if I am wrong.
 
reply
    Bookmark Topic Watch Topic
  • New Topic