This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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'
value object assembler
value list handler
patterns I used in my design were:
transfer objects (but only for two objects that appear in a list)
adapter (for external interfaces)
service (session facade)
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)
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.
Joined: Jun 30, 2008
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.