From Servlet to JSP, from Model1 to Model2

Servlet technology and JSP technology are two main technologies used to develop Web applications using Java language. In 1996, Sun released Servlet technology for the first time to solve the performance problems in Web applications. When the Servlet is first requested by the user, it is loaded into the memory and will remain in the memory. Subsequent requests to the same servlet will no longer need to instantiate the servlet class, this mechanism greatly improves the speed of Web applications. However, Servlet is not so perfect. When people write Servlet, they find that all HTML output code is encapsulated in the String object, and then use the print method of the out object to display it to users, this increases the difficulty of coding, and it is very troublesome to maintain it. Even if a slight change is made, you need to re-compile the Servlet. The emergence of JSP and Related Technologies Sun realized this problem and proposed JSP technology. JSP allows Java code and HTML tags to be mixed together to simplify page development. You do not need to re-compile the page when modifying the page. If the original JSP changes during the first request, the code will be re-compiled automatically, if there is no change, the existing instance is loaded directly. But the problem comes one after another: l mixing of Java code and HTML code (logic and display) makes the program difficult to read and maintain l it is difficult to reuse the code in JSP, this is contrary to the object-oriented idea. l coding IDE in JSP does not support this very well. l Testing becomes difficult. Mixing of logic and display is not promoted by people, as early as JSP1.0 norms, programmers are encouraged to Use JavaBean to encapsulate the business logic code, thus separating the display from the business. But things are not as beautiful as you think. In JSP, the naming conventions must be observed for the methods in the JavaBean, so sometimes the names of a method are very lengthy and difficult to remember. To achieve easier separation between code and HTML, JSP1.1 defines several user-defined tag libraries, which are more flexible and easy to use than JavaBean. However, the old problem is solved, and the new problem arises: the custom tag library is difficult to write, and the custom tag in JSP1.1 has a very complex lifecycle. Later, people began to add some specific common functions to related labels. These Tag Libraries are compiled into several library files, collectively referred to as JSTL (assumerver Pages Standard Tag Libraries, JSP Standard Tag library ). Although the technology such as JavaBean and JSTL can separate the business logic from the display code, many developers still mix the logic with the displayed code in a convenient or short-sighted manner. The Model1 design model has now appeared. The first design model for developing Web applications in Java is called Model1. In short, it only uses JSP instead of Servlet to mix Page code and logic code. From a JSP page to another JSP page is completed through the link in the page. The problem with this mode is mentioned above. It may be easier for small projects to develop. However, for large projects, development is miserable, because this architecture is not conducive to the division of labor between Web designers and Web developers: developers need to participate in page development, it also needs to be involved in the encoding of the business logic. It is even more difficult to maintain. The logic and display code are mixed, and the link between pages is through the link (this means that once the Page name changes, any other page that uses this page must be changed, this is a nightmare for developers. Model2 design Model is the second design Model. We call it Model2. This Model is another name of the MVC (Model-View-Controller, Model-View-Controller) design Model. An application developed based on the Model2 model consists of three main components: model, view, and controller. In the Model2 model, all pages have a common entry point, usually using a Servlet or filter (in which Struts1 uses a Servlet, while Struts2 uses a filter) to act as a controller. The Controller is responsible for receiving changes from user input and controlling the model and view. The view is responsible for displaying application information; the model encapsulates the data and business logic of the application. In such an application, every HTTP request must be directed to the Controller, and the information in the URI of each request may tell this control which actions need to be called. The Controller checks Each URI to determine which actions should be called. It also saves the action object in a place that can be accessed from the view, so that the server value can be displayed on the browser. Finally, the controller uses the RequestDispatcher object to pass the request to the view (that is, the corresponding JSP page), and then the definition tag in the JSP page displays the content of the action object. The entire development process turned out to be: the development of technology was built up by problems. The following will demonstrate how to use Servlet and filter as controllers to implement the Model2 design model. In fact, it can be seen as the demo of Struts1 and Struts2.