aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Retired Patterns Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Retired Patterns" Watch "Retired Patterns" New topic
Author

Retired Patterns

Ali Kianzadeh
Greenhorn

Joined: Aug 31, 2009
Posts: 9
I was looking for JEE 5 Patterns and found a pretty new book which indicate following pattern are retired.
http://www.amazon.com/Real-World-Patterns-Rethinking-Practices/dp/0557078326

  • Service Locator
  • Composite Entity
  • Value Object Assembler
  • Business Delegate
  • Domain Store
  • Value List Handler


  • The problem is that I couldn't find any other resources who confirm that. The reasons author explained are commons sens.

    Since the new SCEA is for JEE5 I thing we should accept these facts.
    Cameron Wallace McKenzie
    author and cow tipper
    Saloon Keeper

    Joined: Aug 26, 2006
    Posts: 4968
        
        1

    Interesting.

    I started a JavaRanch thread on exactly that same topic, wondering what design patterns might not be relevant with moder JEE design.

    Which Design Patterns Are No Longer Needed with JEE5?

    I hear alot about the DAO pattern being retired, which I think it a bit of bunk, but it often gets discussed. It got hit upon in this JavaRanch thread here:

    Hijacking a Thread To Talk About Demise of DAO Pattern

    It is nice to think that as the years progress, the best practices and proven design patterns simply become part of the architecture.

    -Cameron McKenzie

    Celinio Fernandes
    Ranch Hand

    Joined: Jun 28, 2003
    Posts: 548

    Well, I think the Service Locator design pattern is no longer relevant because a nice alternative is dependency injection.


    SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCBCD 5
    Visit my blog
    Cameron Wallace McKenzie
    author and cow tipper
    Saloon Keeper

    Joined: Aug 26, 2006
    Posts: 4968
        
        1

    And it looks like we're tussling up support to retire the DTO pattern. Oh, those pesky Data Transfer Objects:

    JavaRanch SCEA Thread on the Virtue of DTOs

    -Cameron McKenzie

    Mihai Lihatchi
    Ranch Hand

    Joined: Oct 28, 2005
    Posts: 138

    I have always met a lot of resistence in bigger software companies towards getting rid of DTO's. These are the companies that used to do EJB2.0 + Struts instead of Spring MVC ,Spring & Hibernate or other open source frameworks.
    Of course you could send an object from the controller (web layer) to the persistence layer unchanged (Spring && SpringMVC combined with Hibernate would allow that very nicely).
    The issue with eliminating DTO's is distribution - we cannot send a Hibernate entity all the way to another remote web layer and expect it to still perform lazy loading.
    Of course if you believe in the Martin Fowler's first law of distribution (Don't distribute your objects) you might as well consider this pattern retired , I don't.


    Better, faster, lighter Java ... you mean Ruby right ?
    SCEA5,SCBCD1.3,SCWCD5,SCJP1.4 - memories from my youth.
    Hong Anderson
    Ranch Hand

    Joined: Jul 05, 2005
    Posts: 1936
    Transfer Object is not needed in EJB 3 anymore, because EJB 3 promotes using of JPA entities which are POJO.

    And from the facts that Transfer Object is not needed Transfer Object Assembler is also not needed because a Transfer Object Assembler assembles a model from several Transfer Objects.

    We almost never need Service Locator, because EJB 3 introduces dependency injection (But EJB 3 container can DI only for managed resources).

    And who need Composite Entity if we're not using Entity Beans?

    Who need to care Domain Store, EJB 3 already comes with JPA. Even if we don't use JPA, we can use ORM like TopLink, Hibernate, Eclipse Link or Data Mapper like iBATIS.

    Regarding Business Delegate, I don't prefer this pattern because I don't like the idea to reduce dependency between UI Layer and Application Layer. In my experience, if application layer changes and affects UI, just change UI, that is simple.
    And without the need to use Service Locator, Business Delegate now even be less useful.

    I think Sun should publish 3rd edition of Core Java EE Patterns soon.


    SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
    P Das
    Ranch Hand

    Joined: Jun 30, 2008
    Posts: 123
    I would suggest that the Core J2EE Patterns book or website could be a place to get information in respect of retired Java EE patterns, which retired a couple from the version 1 but definitely not all those you have mentioned. Also Java EE blueprint may be consulted.

    I would question authenticity of the view expressed since it would be a process, e.g. JCP, that would have jurisdiction; else, it would be the original creators of those patterns.

    BTW, if you plan for a SCEA 5 (part 1) test, you should not disregard those patterns.

    With SCEA 6 (2010) onwards, we have to wait and see.


    Pranab Das, PMP, SCEA
    Hong Anderson
    Ranch Hand

    Joined: Jul 05, 2005
    Posts: 1936
    P Das wrote:
    With SCEA 6 (2010) onwards, we have to wait and see.

    Where did you heard about SCEA 6 from?
    P Das
    Ranch Hand

    Joined: Jun 30, 2008
    Posts: 123
    Hmmm, let me see. Looks like there is an emerging standard of Java EE 6. The current SCEA is based on Java EE 5. JSR 316, if I am not very mistaken describes the latest one. It describes such things as JAX-RS 1.1 and quite some improvements over last version.

    I probably seen somewhere that SCEA 6 will come up around 10/2010.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Retired Patterns