Entity Bean are said to be an ideal representation of Business Data in J2EE. What are the trade offs? Why application programmers hate about entity beans even in the era of strong application server support improving every day? Where to use entity beans and what are other better alternatives? Please add your valuable real time development experiences with entity bean. In the second phase of my one J2EE application, my project tech leaders have strongly recommended for replacing all entity beans with database side procedure and session beans. I am not happy about it but have no other way to show entity beans are real good. Thanks!!! Java - make things beautiful!
Hi, I am sure about one dis advantage of going to procedures. i.e., it makes it purely database dependent. Its not possible to bind those logics to a different RDBMS when you switch over later.
Entity beans provide a way to avoid this situation. You can Entity beans as Objects mapped to the tables of your database, so that you can easily use it in your code and dont have to worry about connecting to database etc. Just take the tables in your DB as objects and go with your coding part and rest of the things like connection pooling on ur DB, transaction on the DB etc is container's head ache.
naren,I am sure reading the "Bitter EJB" book would answer many of your questions
Arun,I agree with your point that using procedures makes us dependent on the DB.But what if, the organisation has decided clearly about the brand of database server?Do you still think its a disadvantage to use the specific optimisations and features provided by that vendor?Also there are many tools which *claims* to ease the porting of the code from one type of DB to other(Although i am not sure they can do a 100% automatic conversion) IMO,the locking of the business logic in the DB,reduces the reusability of the logic.Also the code clarity reduces as the size increases.This is the only fact which might be off a important concern when choosing a procedure.