Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Retired Patterns

 
Ali Kianzadeh
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 4968
    1
    Hibernate Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 549
    Eclipse IDE Google Web Toolkit Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Well, I think the Service Locator design pattern is no longer relevant because a nice alternative is dependency injection.
     
    Cameron Wallace McKenzie
    author and cow tipper
    Saloon Keeper
    Posts: 4968
    1
    Hibernate Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 138
    Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    P Das
    Ranch Hand
    Posts: 123
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 123
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic