- Posted by: Johan Henricsson
- Posted on: February 19 2001 05:24 EST
I have just started to learn about J2EE, and no I'm planning to build a little Web-Shop (just for learning).
In the project I'm planning to use a Servlet as a Request Controller, which all Http requests are made to, and then forward the requests to differend JSP's. My wondering is, if the Request Controller takes care of calling EJB's and such stuff, for example getting information about a specific product, how do I give this information to the JSP that should finally view the information? Should I put in the Session? If so, doesn't that mean that I end up with a copy of the same information for every different user in the system (if the all look at the same product)?
Another wondering is, should I cache product information at the Web-layer instead of getting it from the entity beans for every request? If so, how do I detect changes?
- Request Controller and JSP's by Mils Smith on February 19 2001 08:08 EST
- Request Controller and JSP's by Mils Smith on February 19 2001 08:43 EST
- Request Controller and JSP's by Johan Henricsson on February 19 2001 15:42 EST
Well the way I understand it is this (and please feel free to correct me if I am wrong!)...
Having the controller call the EJBs fits with the MVC architecture, but the only way to get the information to the page from the controller is to use the session, or a session or request scoped bean.
You could also back your JSP page with a page bean, and get that to call the EJBs, and that is what we have done (slight variations, we have a JSP controller, backed by Java classes, as one controller servlet for a large application can get very big!).
We have some calls to the business logic of the application from the controller, for actions (receiving form submissions, logging in and things like that), and then based on the results of that, a users is forwarded to a page. All pages are backed by beans.
For example, if a user was to create a newsgroup posting, the form submission would be handled by the controller for inserting the information into the database, the controller would call and EJB for example. The page that the controller returns might be a page displaying all discussions in the newsgroup. This page is backed by a Page Bean that gets this information using another EJB.
Let me know if this answers your question.
Have you had a look at the Struts architecture http://jakarta.apache.org/struts/, might answer some questions as well.
Another good Struts and MVC-2 architecture article...
Thanks for the answer, I think it helped me a bit.
As I understand, it's quite common to implement this kind of application in the following manner:
The Controller Servlet takes some input from the client, for example that it should show all products in some kind of category. In this case it gets this information from a SessionBean, and the SessionBean gets the information by getting all Product EntityBeans. The SessionBean doesn't return the EntityBeans, instead it return normal JavaBeans that contain the same information as the Product EntityBean. The controller puts these JavaBeans in the request scope, and then forwards the request to a Products-Lister-jsp. The jsp gets the product-information from the JavaBeans bound to that request and displays it.
Is this right? Is this good design?
What you are saying would work fine, but it is more common for a Controller Servlet to take input from the client, and make updates as required such as saving information to a database (form submission), and if all you are doing is displaying the contents of a catalog, then the Controller Servlet need to nothing other than forward the request to a JSP page. The JSP page can then have an associated page bean (not an EJB, but a plain ol' bean with Page scope) which connects to an EJB (or just plain Java classes) to get the information to display on the page.
It may sound like the Controller Servlet is doing nothing much here at all, just sending a forward to a page. You could just navigate to the JSP page yourself, and all would work fine (the JSP page would instantiate the page bean, and data would be extracted). But the idea of using a Controller Servlet (the first part in using MVC architecture for the web) is to allow a central place for the "control" to happen.
Figure 5 on this page....
...shows it quite well.
Here the Controller Servlet dispatches requests to business logic as required. These could be saving form entered information to the database which updates the Model (application state, or data). In your case, viewing a catalog, this may be nothing at all, i.e. no change is made to the Model (application state, or data).
The the View which your request is forwarded to, which is a JSP page, obtains information from the Model (application state, or data) to populate the page. In the picture they are using custom tags (this is what Struts use). The other way is to use Page Beans, which are easier to implement.
This is quite common, and actually it looks like it is the preferred method for developing complex web sites, especially web applications. There are pro's and cons's of every design, but if you are building anything serious (or building a "training" site to gain skills), then this is quite a good architecture.
Hope this helps!
Thank a lot for taking time helping newbies like me.
I think I understand enough to get started now. I'll use a controller servlet to update the model and page beans for accessing the model from the jsp's.