• 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

JEE pattern with JEE5

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi there,
I am working on my assignment to part 2.
From the forum and postet user experience it looks like to me, 'more pattern = better design'.
people who scored really good, used almost any JEE(2) pattern.

I have built my assignment with full functionality to verify all use cases will be satisfied and also to generate the class diagram using 'import java'.
It works quite good and the design is very clear in my oponion.
I omited many patterns, which Adam Bien marked as 'retired pattern'
in detail:
service locator
composite entity
value object assembler
business delegate
domain store
value list handler

patterns I used in my design were:
singleton
transfer objects (but only for two objects that appear in a list)
adapter (for external interfaces)
service (session facade)
composite view

design in short words is:
backing beans using session beans local interfaces
(detached)jpa entitites used in ui (except the mentioned 2 transfer objects)
strict coupling of functional components (which means polymorphic navigaton in datamodel)

do you think, this is gonna get me in trouble?
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you are fine. By using frameworks, a lot of patterns occur behind the scenes and aren't explicitly in your code.

And more patterns isn't always better. There is a tipping point where more patterns are redundant and confusing.
 
wolfgang unger
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks jeanne
 
Ranch Hand
Posts: 123
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have been using, with benefit, many of the patterns marked "retired" in the above list; also, I used some in my assignment submitted some time ago.

Is there any change in the guidelines, or it is again some personal opinion? I ask this because http://www.corej2eepatterns.com/Patterns2ndEd/index.htm did not retire them.
 
wolfgang unger
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,

as your link already says, these are j2ee pattern.
the new jee5 features make many of these patterns obsolet.
the only book that covers jee5 and pattern is 'real world java ee patterns' from adam bien. at least, I don't know another one.
he describes new concepts for jee5 and also marked some of these old j2ee pattern as retired.
e.g. for the service locator:
Reasons for Retirement
•Dependency Injection is available in most Java EE components. JNDI lookups are no longer required to access other session beans or resources.
•The creation of a home interface became optional, and therefore the creation of remote and local interfaces.
•PortableRemoteObject.narrow is optional in EJB 3.0—the session bean can be accessed with simple Context#lookup.
•The complexity of the infrastructural code was greatly reduced by the EJB 3.0 specification. A Service Locator would not further reduce the complexity of the code; on the contrary, it would increase it. You should use Dependency Injection whenever possible and only in exceptional cases a generic Service Locator implementation.
•For the exceptional cases a specialized Service Locator form, the BeanLocator, can be used.

of yourse it's no dogma, but in my opinion these new concepts make a lot of sense. kepp it simple stupid (jee5 is still not simple).
j2ee with all it's pattern and overengineering was the reason, peple rather used spring or anything else but j2ee.
 
P Das
Ranch Hand
Posts: 123
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
imho, the reason for using lightweight, special purpose, frameworks, such as spring, is something that is still not provided in jee or rather not addressed differently from j2ee. implementing some of the patterns in jee may not be the cause to "retire" them altogether from the point of view of developer preference in using one or the other versions of java or other framework, as mentioned by you. Coming to the basic question, I understand that none of the patterns mentioned have been "retired" by Sun/Oracle for the purpose of SCEA exam. However, it depends on individual exam takers personal choice. Hope, I am sufficiently clear.
 
See ya later boys, I think I'm in love. Oh wait, she's just a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic