Hi all, after having read some books and articles about ejb, I am wondering what�s the benefit from [BMP] Entity Beans and what would one loose if completely leaving them out. In the intro of EJB resources it always says "the functionality of the app server let�s the developer concentrate on the business problem by shielding him from technical stuff". With the "n+1" problem and fat key pattern stuff in mind, one should add to the statement "[ps: for real technical transparency the developer has to accept poor performance]"?!
Inspired by the Chapter "Alternative to Entity Beans" [EJB Design Patterns], I am asking what�s at stake in the following scenario preventing the use of Entity Beans: - Use of Session Facade and Data Transfer Object Patterns - Use of Data Access Objects wich are used by Session Beans to read and write to the persistence layer. The first thing wich comes into my mind is resource pooling. Since Entity Beans are being pooled this should be one tradeoff when not using Entity Beans. But what more? 1: Maybe Concurrency? Since the access of the DAOs is shielded by session Beans, it shouldn't be a problem, should it? 2: What about transactions? Is there a problem with data integrity when updating data with DAOs and not with EJBs? 3: What about transaction handling? With Entity Beans it should be possible to set the isolation level for each Entity Bean method, wich is not possible with "simple" DAOs. Right? 4: Distributed Transactions: TA-handling over more than one persistence store would have to be coded manually with JTA? 5: Reuse: It should be much easier to reuse an EJB than a DAO? 6: ????? =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
