EJB or JSP

Question

Hi, I am trying to develop an application where the task is to search the underlying database tables based on web based user input (multi-user environment) and display the results back. One possible approach I could think of is to have my JSP pages do the connection pooling, database lookup etc. and display the results back to the browser and the other approach is to use EJBs. In the second approach my JSP pages are just clients to the EJBs and EJBs perform the actual business logic and database retrieval. Now my question... Which of the above two appraoches is more feasible? What are the advantages/disadvantages of using one over the other?? Does use of EJBs cause an extra overhead and result in poor performance?? In future we might extend the application for even database updates and inserts. Please let me know your thoughts. Thanks..

Answer 1

My two cents: If you are trying to code for reuse and maintainability, you follow the MVC (model, view, controller) paradigm and you cleanly separate the layers of applications. In this scheme, the view knows NOTHING about where the data came from to display on the screen. The data access mechanism has no knowledge of HOW the data it supplies is going to be used, etc. The obvious advantage of this is that this loose coupling of layers allows a developer to CHANGE the specifics of one layer without forcing the other layers to change. For instance, if you move data from one database table to another one and you have 40 JSP pages that all use this data, if they each directly access the DB, all pages have to be modified for the change. And if the pages all use a connection pool and the connection pool changes, you still modify all the pages. Instead, if all the pages simply ask some Java object (a simple class, a Session Bean, controller, etc.) to get the data they desire (i.e., "getCustomerAddress(aCust)"), then no matter where the data moves or what connection pool changes occur, none of the JSP pages has to change and be tested again.
Of course, the tradeoff is performance. There is no free ride. For most business applications today, the main concern is flexibility and rapid change. So the clean separation of layers and coding for maintainability is usually a winner. However, there will always be places in the app where you might have very critical timing/performance issues. So FOR THOSE PLACES, you might want to use alternative methods of accessing and saving data.
It should not be ALL or NONE. As you architect the application, you decide where the bottlenecks will be, where the most frequent changes are likely to occur in the business logic, and you design accordingly to give the users maximum performance AND adaptability.
That's my take on it.
Dave