File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes JEE pattern with JEE5 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "JEE pattern with JEE5 " Watch "JEE pattern with JEE5 " New topic
Author

JEE pattern with JEE5

wolfgang unger
Greenhorn

Joined: Oct 30, 2010
Posts: 28
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?


Senior Consultant/Software Architect
SCJP, SCEA
facebook: JEE Java Enterprise
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29237
    
139

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
wolfgang unger
Greenhorn

Joined: Oct 30, 2010
Posts: 28
thanks jeanne
P Das
Ranch Hand

Joined: Jun 30, 2008
Posts: 123
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.


Pranab Das, PMP, SCEA
wolfgang unger
Greenhorn

Joined: Oct 30, 2010
Posts: 28
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

Joined: Jun 30, 2008
Posts: 123
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JEE pattern with JEE5
 
Similar Threads
95% for Part II/III
Design Pattern
Difference Between Composite Entity and Transfer Ojbect Assembler
about a very BIG confusion in design pattern.
Architectural patterns with EJB 3.0