Relationship DAO, Servlet, JSP and POJO

I want to implement a JSP, POJO, DAO and Servlet in my J2EE program. However, I don’t fully understand how the relationship between these elements should be. Is the following (MVC) setup the right way to do it?

Main class creates servlet(controller)
Servlet has a DAO defined in its class
DAO has a POJO defined in its class
Servlet communicates with the view (JSP page)

Please give your feedback.

Answer is quite big. but here it is

As you are following MVC design pattern.So, I’ll describe in

View = jsp, html, javascript exists

Controller = servlet

Model= Dao

Basically in servlet calling your DAO to get data from DB.
But throughout the application there are many Variables so for that you need bean. i.e
POJO

Lets go by hierarchy of project that you will create in eclipse.

Here u can see in source folder where we have “test” folder which is main package and under that different we have sub packages.

Here we can put servlet’s in controller. your POJO is in bean. DAO has dao class.
And util has different class of custom utility like custom date, password encryption.

and finally you will have webcontent folder will have jsp pages.

Now flow would be first user input from jsp page. would be

JSP==>Servlet(Here you can set parameter to POJO send instance to DAO)==>DAO==>DB

And last but not least is web.xml which is deployment descriptor and which used by container or web server to handle request.

Lets start……..

IMHO there’s multiple issues here:

1 . To me the MVC pattern, like the Quantum Theory has multiple interpretations

AFAICS: there’s two major ways to do MVC:

one where the controller actively tells the view to update once he (the controller) has updated the model
one where the view “sees” the model updates and updates itself in turn without any exterior help

In a simple Servlet and JSP setup you’re pretty much in the first interpretation of the MVC pattern, where the servlet does whatever (more on this in a minute) and then creates the model, followed by telling the JSP view to update itself so that the new model shows up in the view.

I’m stating all this because if you want to go about the 2nd MVC interpretation as stated here, you’ll usually have to use a lot of JavaScript in the View to enable it to listen for your model changes and update itself.

At any rate, no matter which one you chose the 2nd major issue is:

2 . Establishing how these components will match up to the Model, View and Controller entities:

one way to go about it is to have the Servlet as Controller. This means you’ll (usually) have multliple servlets, each controlling one or more views. The views in turn are JSP pages. Now, the controller servlet should only deal with creating the model (not deal with presentation stuff) and the JSP view should only care about using the model for presentation (not adding to the model-construction work the servlet controller has already done). This tipically means having a Servlet with one or more DAO (or other business service components) instances, which will be used to fetch the model data, and once that’s done, he’ll place it where the JSP view can reach it (usually in request or session scope) and reload the view. The JSP in it’s turn only knows that when it’s loaded it’s supposed to find the model data at some place, and present it in a certain way.
a somewhat better way to do this is to have non-servlet components (classes) for the controller. These controllers are notified by one or more “facade” servlets depending on the HTTP Request content (URL, parameters, etc, there’s usually some kind of mapping between various combinations of HTTP Request elements and corresponding controller intances). In this way the controller really deals only with creating the model and notifying the view, it doesn’t deal with the low level HTTP stuff.

Finally, as a side note, you should know that a Servlet, in order to be instantiated, must be deployed in a Java EE Web Server (like Tomcat), there’s no “main” method (not one that you have to write anyway) where you manually instantiate them.

3 . About the Facade Servlet and separate (non-servlet) controllers

The idea here is to separate the low level transport/communications stuff from your MVC implementation. The MVC doesn’t really specify anything about such things, and indeed there’s no obvious place for them in a MVC implementation. On the other hand your Servlet does do HTTP, that’s how it works. So taking all these into account it’s good to NOT make the Servlet into a MVC controller, but rather have it only deal with incoming HTTP requests and then dumbly just pass them on to the appropriate controller, effectively acting as a Facade for all those controllers back there.

In practice what you can do is decide upon a system which will map an HTTP Request to a controller:

you decide what part of the HTTP request is taken into account to identify a controller. Typically it will be the request URL such that when an incoming request for “/mySite/listProducts” comes in, the Facade servlet will extract the relevant information from the request and pass it to the corresponding controller, then wait for said controller to prepare the model and display the view
you decide how to actually implement this mapping. You can just make a flat file stating things such as the URL pattern and the corresponding Controller class or instance, something like this:

/mySite/listProducts myProject.controllers.ProductsListController
/mySite/productDetails/* myProject.controllers.ProductDetails

In the above example, I’ve chosen a wider URL pattern for the second controller, because the specific URL demanding for Product Details might contain at the end of the path some kind of identifier for the specific product it wants details on, something like /mySite/productDetails/pinkFedoraHat and I want any and all such requests to go to the ProductDetails controller

Then when the app starts, the Facade Servlet is configured with this file, and then instanciates and delegates to the needed controller.

a second mapping you might need to do is between controller and view. You may want one controller to redirect to multiple views, depending on how it was addressed. You can do this similarly by making an URL pattern to JSP map. However this is really optional.

Also, as this is a pretty obvious pattern, there are already implementations of it in various Java frameworks: Strust2, Spring MVC, (these 2 are for the first type of MVC, the controllers-nudges-view-to-update type), Ember JS (this is a JavaScript library and gives you the view-is-smart-enough-to-update-itself-upon-model-update variant). What I recommend is that you first try to implement some simple examples without these frameworks, so you can get a good idea of how this works, and then use one of these for more involved projects as the boilerplate code to implements this can get pretty unwieldy when doing it all by hand

In MVC pattern,

Servlet is the controller(C)

JSP page is view (V)

POJOs and DAOs are Model (M)

A user sees the jsp page and interacts with it. When a user submits a request(clicks a button), jsp sends it to the servlet you have defined.

Servlet which is a controller may create a POJO, store data sent by the user in it and passes it on to the DAO.

DAO queries the database and sends it back to the servlet and the servlet passes the data back to jSP again.

Filed under: softwareengineering - @ 21:29

Thẻ: design-patterns, java-ee, relationships

Thiết kế website giá rẻ

Danh mục

Relationship DAO, Servlet, JSP and POJO