Why use a Controller Bean?
843829Sep 22 2003 — edited Sep 23 2003I'm new to J2EE and read through the J2EE tutorial and came across the Duke's Bank Application which is a simple example for beginners to explore and learn.
I understand the need for 3 entity beans, CustomerEJB, AccountEJB and TxEJB. They're primarily there for the database persistence.
Then there are 3 controller beans: CustomerControllerEJB, AccountControllerEJB and TxControllerEJB. In the tutorial explanation, it says that they're there to "provide a client's view of the application's business logic" and to hide the "server-side routines that implement the business logic, access databases, manage relationships, and perform error checking".
I used to have the thinking that the business methods should also be put in their respective entity EJB; the business methods have already been separated from the server-side routines (as the tutorial calls them) using the remote and home interface of the EJB respectively. So why do we still need to separate them further into 2 EJBs?
If this is the case (assuming there is some merits in using Controller Beans), won't every entity bean have an accompanying session bean to expose the business methods?
Another question is why are all these controller session bean stateful instead of stateless as they're just ? Is it because they've to keep track of which user (customer or bank admin) they're serving?