This content has been marked as final. Show 4 replies
The session bean should not concern itself with data access logic because how the data is accessed should not be coupled with the business rules since they change independently of each other.
In the pattern given, the data access logic has already been hidden away in the DAO pattern so the session bean can call the DAO without introducing a dependency on how the data is accessed.
You solution just adds another layer without really simplifying anything.
946651 wrote:For some applications yes (I hesitate to say: most), for some, likely those with more complex transaction management requirements, the additional layer is actually a benefit. Its all a matter of perspective; for example if you use JPA then you can argue that that is already a 'dao' and you don't need yet another DAO layer.
i.e. Core J2EE Pattern a session facade i.e. Enterprise Session Bean can directly call Entities and DAOs which seems to me adding more complexity to the system rather than reducing.
The heart of the matter is: just because that article exists doesn't make it the truth. Do what you think works, not what Sun thought worked.
First of All thanks a lot for considering some time.
EJB's are meant for complexed enterprise solutions, I don't recommend EJB's to use for a shopping cart like application. I mean a lot of complexity, transaction management, security, load balancing, clustering bla bla, is involved for such an enterprise solution.
In such particular case I think layers reduces complexity and Enterprise Session Bean is only meant for a proxy like stuff to the particular handler for further processing.
Regards and Looking Forward:
Asad Ali Rathore.