if from client code we directly access entity beans then what
kenji kunoichi
Ranch Hand
Posts: 46
posted 9 years ago
Kenji,
I can think of two reasons.
1) Performance - the network traffic would be a killer. There would be way too many round trips which would make the performance really slow.
2) Encapsulation - the client would know to much about your implementation details. Which means you could never change them. Whereas a session bean lets you hide this logic from the client and have them request things on a higher level. That way the client can get "account data" without caring how many tables it is called in.
I can think of two reasons.
1) Performance - the network traffic would be a killer. There would be way too many round trips which would make the performance really slow.
2) Encapsulation - the client would know to much about your implementation details. Which means you could never change them. Whereas a session bean lets you hide this logic from the client and have them request things on a higher level. That way the client can get "account data" without caring how many tables it is called in.
[OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
aleem khan
Ranch Hand
Posts: 94
posted 9 years ago
If you don't use session beans then where would you put your business logic? Entity beans are mere representation of data which is in object form. And as per EJB 3.0 speicification an EntityBean will now be managed by separate API called JPA(JAVA PERSISTANCE API)... We dont require EJB container anymore to run Entity Beans, it is like plain old java object now.
The other issue could be performance. Imagine if 2000 users are using
the application. It has to make 2000 remote calls to Entity beans i,e indirectly to database which could be costly affair and very slow in performance or the server may even crash. If we session beans in between
EJB 3.0 container would take care of Multithreading, security, transaction and would easily handle 2000 users . Then local call from entity beans to database would be fast. Hope it is clear now
The other issue could be performance. Imagine if 2000 users are using
the application. It has to make 2000 remote calls to Entity beans i,e indirectly to database which could be costly affair and very slow in performance or the server may even crash. If we session beans in between
EJB 3.0 container would take care of Multithreading, security, transaction and would easily handle 2000 users . Then local call from entity beans to database would be fast. Hope it is clear now
SCJP(1.4), SCWCD, Oracle 9i SQL certified, Oracle PLSQL Developer Certified Associate
Z Sugiarto
Ranch Hand
Posts: 58
posted 9 years ago
"why the hassle of having a layer of session beans if I can just use those entity beans directly?"
having more layers (if designed correctly) will make the system to be more 'expandable': - better maintainability, better support for future modification and so on.
Think of the design as a foundation for growth, so if the foundational design and implementation is good, it can evolve quite far in the future.
But if the system will not have such a need in the future, and only used by very few people (i.e not 'enterprise' in any significant way) then you probably don't have to worry that much into having such elaborate foundation structure in your system.
However in such a scenario, you should probably evaluate as to whether or not you REALLY want to choose EJB to build your solution.
If you wanted to access your 'persistance-aware' objects directly from the client, there's stuff like Hibernate or Toplink that you can use too...
[ August 30, 2008: Message edited by: Zenikko Sugiarto ]
[ August 30, 2008: Message edited by: Zenikko Sugiarto ]
having more layers (if designed correctly) will make the system to be more 'expandable': - better maintainability, better support for future modification and so on.
Think of the design as a foundation for growth, so if the foundational design and implementation is good, it can evolve quite far in the future.
But if the system will not have such a need in the future, and only used by very few people (i.e not 'enterprise' in any significant way) then you probably don't have to worry that much into having such elaborate foundation structure in your system.
However in such a scenario, you should probably evaluate as to whether or not you REALLY want to choose EJB to build your solution.
If you wanted to access your 'persistance-aware' objects directly from the client, there's stuff like Hibernate or Toplink that you can use too...
[ August 30, 2008: Message edited by: Zenikko Sugiarto ]
[ August 30, 2008: Message edited by: Zenikko Sugiarto ]
