aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes opinion: Data Transfer Objects: pattern or anti-pattern (EJB3) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "opinion: Data Transfer Objects: pattern or anti-pattern (EJB3)" Watch "opinion: Data Transfer Objects: pattern or anti-pattern (EJB3)" New topic
Author

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

Logan Lee
Greenhorn

Joined: Oct 28, 2009
Posts: 18

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
    Jimmy Clark
    Ranch Hand

    Joined: Apr 16, 2008
    Posts: 2187
    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.
    Hong Anderson
    Ranch Hand

    Joined: Jul 05, 2005
    Posts: 1936
    If you're not using remote interfaces, no need to use Transfer Object, end of story.


    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
    Jimmy Clark
    Ranch Hand

    Joined: Apr 16, 2008
    Posts: 2187
    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

    Joined: Jul 05, 2005
    Posts: 1936
    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

    Joined: Oct 28, 2009
    Posts: 18

    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

    Joined: Jul 05, 2005
    Posts: 1936
    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

    Joined: Apr 16, 2008
    Posts: 2187
    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

    Joined: Jul 05, 2005
    Posts: 1936
    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

    Joined: Apr 16, 2008
    Posts: 2187
    lol .. all these references, names and website URLS, it looks like your also certified in Web Searching and Referencing.

    Good luck!
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: opinion: Data Transfer Objects: pattern or anti-pattern (EJB3)