• 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

opinion: Data Transfer Objects: pattern or anti-pattern (EJB3)

 
Greenhorn
Posts: 18
Mac Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying out EJB3/JPA with the use of design patterns.

In all the examples I've build myself I never used DTO's. I always considered DTO's to be an anti-pattern.
I don't want code duplication. EJB3 Entities are not bound to the container anymore and they can move across my tiers. There is no need create DTO's to carry Entity data.

But now I was having a look at the book 'Beginning Java EE5 from Novice to Professional (Apress 2005)' it has a chapter about Design Patterns and EJB.

It states that you should use DTO's because it's not good practice to allow clients to have remote references
to entities.

  • Calling entity bean methods directly circumvents the business logic contained in session beans, and tends to push the business logic into the UI code.
  • Session beans can protect the UI from changes to the entity beans.
  • Restricting client access to session beans conserves server and network resources.


  • In my view layer (or a client) I would never call a method directly on my entities.
    If I am going to execute BL, I would always go via a session bean. If a user fills in a form, I just re-use the ejb3 entity to populate the fields he just entered and pass that entity to my session layer.

    I don't understand why they are using DTO's. Probably I am missing something here?
    Do you use DTO's in your EJB3 application? Why?

    Thanks in advance.
    Logan
     
    Ranch Hand
    Posts: 2187
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The Transfer Object design pattern does not specifically dictate any single "implementation". You can certainly use the Entity object as a Transfer Object. There is no code duplication because there is only a single class.
     
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    If you're not using remote interfaces, no need to use Transfer Object, end of story.
     
    Jimmy Clark
    Ranch Hand
    Posts: 2187
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The Transfer Object object-oriented design pattern is very important for properly designing three-tier applications. It does not matter if you are using "remote interfaces" or not.

    You can develop a three-tier application in a crappy, tightly-coupled way without using Transfer Objects.

    Or, you can develop an efficient, streamlined three-tier application in a great way.

    The choice is yours

    P.S. My advice above is for large-scale enterprise applications only...if you are still working on Jim Bobb's Cardboard company website with 20 visitors a month, no need for Transfer Object.
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    James Clarks wrote:The Transfer Object object-oriented design pattern is very important for properly designing three-tier applications. It does not matter if you are using "remote interfaces" or not.


    The most important purpose of the Transfer Object pattern is to reduce remote calls, if we're not using remote interfaces, no need to use Transfer Object.

    Transfer Object pattern was heavily used in EJB applications because Entity Beans are remote objects, so it's a must to apply this pattern (or "workaround" would be a better term).
    Otherwise, if an object has 10 attributes and if a single user queries 100 objects, it would result in 1,000 remote calls for only single user, no need to say what would happen if there are 300 concurrent users.

    Entity beans, on the other hand, are multiuser, transactional objects representing persistent data. An entity bean exposes the values of attributes by providing an accessor method (also referred to as a getter or get method) for each attribute it wishes to expose.

    Every method call made to the business service object, be it an entity bean or a session bean, is potentially remote. Thus, in an Enterprise JavaBeans (EJB) application such remote invocations use the network layer regardless of the proximity of the client to the bean, creating a network overhead. Enterprise bean method calls may permeate the network layers of the system even if the client and the EJB container holding the entity bean are both running in the same JVM, OS, or physical machine. Some vendors may implement mechanisms to reduce this overhead by using a more direct access approach and bypassing the network.

    As the usage of these remote methods increases, application performance can significantly degrade. Therefore, using multiple calls to get methods that return single attribute values is inefficient for obtaining data values from an enterprise bean.

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

    EJB 3 promotes the use of JPA in which JPA Entities are POJOs, therefore displaying 100 objects in View Layer result in zero remote call. Applying "Transfer Object" in this case doesn't help anything but introduce duplicate classes.

    However in some cases we can create "Value Objects" [DDD, Fowler], which is totally different from "Transfer Objects".
     
    Logan Lee
    Greenhorn
    Posts: 18
    Mac Spring Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Kengkaj Sathianpantarit wrote:
    EJB 3 promotes the use of JPA in which JPA Entities are POJOs, therefore displaying 100 objects in View Layer result in zero remote call. Applying "Transfer Object" in this case doesn't help anything but introduce duplicate classes.



    Indeed, that also was my opinion.


    Kengkaj Sathianpantarit wrote:However in some cases we can create "Value Objects" [DDD, Fowler], which is totally different from "Transfer Objects".



    What is the exact difference. When I google it I see references to TO's?
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Logan Lee wrote:

    Kengkaj Sathianpantarit wrote:However in some cases we can create "Value Objects" [DDD, Fowler], which is totally different from "Transfer Objects".



    What is the exact difference. When I google it I see references to TO's?


    Value Objects [DDD] means objects that have no conceptual identity. We can create a Value Object from multiple Entities (actually we can create a Value Objects from anything).

    Value Object [Fowler] means simple objects that have no conceptual identity.
    http://martinfowler.com/eaaCatalog/valueObject.html

    Note that the original name of Transfer Object [Core J2EE Patterns] is Value Object [Core J2EE Patterns].
     
    Jimmy Clark
    Ranch Hand
    Posts: 2187
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    However in some cases we can create "Value Objects", which is totally different from "Transfer Objects".




    Note that the original name of Transfer Object is Value Object.




    lol..."Value objects" or "Transfer objects"...sounds like your playing with words. What is being tranferred...values?
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    James Clarks wrote:"Value objects" or "Transfer objects"...sounds like your playing with words. What is being tranferrred, values?


    These two terms can sometimes cause confusion especially in J2EE community because early J2EE literature from Sun Microsystems used the term "Value Object" for this pattern, and later it was renamed to "Transfer Object" which is more accurate and consistent with other literature. P of EAA and Microsoft Enterprise Solution Patterns use the term "Data Transfer Object" for this pattern.
    http://martinfowler.com/eaaCatalog/dataTransferObject.html
    http://msdn.microsoft.com/en-us/library/ms978717.aspx


    Martin Folwer has his own term, "Value Object" in his book (PEAA) means differently from "Value Object" [Early Core J2EE Patterns's term] as mentioned in my post above.

    Value Objects in Domain-Driven Design [Eric Evans] also means differently from Martin Fowler's, Value Objects [DDD] means objects that have no conceptual identity, in other words, they are general objects that have values.

    Sorry about my post above. I wasn't clear enough. I should say this:
    Note that the original name of Transfer Object [Current Core J2EE Patterns] is Value Object [Old version of Core J2EE Patterns].
     
    Jimmy Clark
    Ranch Hand
    Posts: 2187
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    lol .. all these references, names and website URLS, it looks like your also certified in Web Searching and Referencing.

    Good luck!
     
    reply
      Bookmark Topic Watch Topic
    • New Topic