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.
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
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.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.htmlEntity 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.
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
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.
Kengkaj Sathianpantarit wrote:However in some cases we can create "Value Objects" [DDD, Fowler], which is totally different from "Transfer Objects".
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?
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
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.
James Clarks wrote:"Value objects" or "Transfer objects"...sounds like your playing with words. What is being tranferrred, values?
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