MODEL is the object that truly handles the user request and saves the result of the user's request and saves the processing result. In the whole process, we generally use JavaBean to save some information to pass between individual objects. Because in the framework, the Model object is an object that is truly processed business logic, so it is part of the application demand in the framework to achieve the most dependence. In the implementation of Struts, the specific expression of Model is the Actionform object and the Action object corresponding to it. Check the data of the user to the form, and even preprocess data can be done in the actionform. In the usual application, it is generally a model object and a relationship corresponding to a request page, but it is also possible to correspond to multiple page requests with a Model object. If the struts-config.xml configuration file does not specify an Action corresponding to a Model object, the controller will directly put (complete data package through the Model object) to a View object. The following figure shows the hierarchy of Model Layer.
In Struts, Model exists in the form of one or more Java Beans. These beans are divided into three categories: Action Form, Action, JavaBean or EJB. Action Form is usually called FormBean, encapsulated user request information from Client, such as form information. Action is often called ActionBean, obtains the FORMBEAN from ActionSevlet, takes out the relevant information in the FormBean, and makes relevant processing, usually call JavaBean or EJB. Many demand documents will build a focus of web applications on the view. We must ensure that each submitted request has been defined in the model view. Typically, developers focus on developing a JavaBean class in the model assembly to implement all of the functional requirements. What beans should be used accurately, depending on its demand, it is great, but it usually can be subsequently categories after distinguishing. Second, create a Model component 1, JavaBeans can save (and access) JavaBeans using many different "Attributes" collections in a web foundation. Each collection has its own different life cycles and what is visible to where Beans is stored. At the same time, Beans defines life cycle and visibility rules through the scope. Defining scope selections in the JavaServer Pages (JSP) specification uses the following items (equivalent concept definitions in the servlet API) in parentheses). Page: Beans will only be seen in a JSP page, exist only in the current request cycle. (Local variables in the service method) Request: Beans will only be visible in a JSP page, with page the same or servlet, or forward to this page. (Request Attribute) Session: Beans can be used by all JSP pages and servlets through specific user sess, which can span one or more requests. (Session attribute) Application: Beans can be used by all JSP pages and servlets in the web application. (Servlet Context Attribute) We need to remember that the JSP page and servlets in a web application share the setting of the bean collection. For example, in a servlet stores a bean to Attribute as follows:
MyStudy MyStudy = new mystudy (...); Request.SetAttribute ("Cart", MyStudy);
After this servlet forwards the request to a JSP page, we can immediately use the standard action tag (TAG) to see the corresponding value:
2, Actionform Beans
In the eventual properties of Actionform Beans, when the property is equivalent to our Model Beans, the Form Beans They should consider becoming a controller component. Similarly, they can deliver information between models and view layers.
The Struts framework typically assumes that we have defined an Actionform Beans in our application (in short, an extended Java class that extends from the Actionform class). Actionform Beans sometimes only calls Form Beans (Form Beans). This may be a fine-grained object that allows each form to correspond to a bean, and a bean service is in a case where a few forms and even all applications form a coarse particle size.
If you define beans in our Struts configuration file, Struts' Controller Servlet will automatically provide us with the following services before calling the appropriate action method:
Check if there is an instance of the Bean in the user's appropriate scope (Request or Session) using the appropriate keyword.
If there is no such instance available, a new BEAN instance is automatically created and the period is added to the appropriate scope (Request or session).
For each request parameter, the corresponding setter method is set to the corresponding setter method to set the corresponding setter method to set the corresponding setter method. This method is similar to the standard JSP to use the
The updated ActionForm bean is passed to the Execute method of an action class [org.apache.struts.Action] so that these values can be used by our system status and business logic beans.
We should pay attention to a "form" here is not necessarily corresponding to a separate JSP page in the user interface. It is also common to extend to a "form" in many applications to multiple pages in many applications. Think about it, for example, the user interface of the navigation program used in the installation of the new program. Struts encourages us to define a separate ACTIONFORM BEAN containing all field properties instead of which is actually displayed on which page. Similarly, different pages of the same form should be submitted to the same Action class. If we follow this suggestion, in most cases, the page designer can reorganize fields in different pages without changing processing logic. A small app may only need an actionform to provide services for all input forms. Other applications can use an ActionForm for each large subsystem. Some people may prefer to use different Actionform classes for each input form or workflow. How do I use ActionForm is completely in us, and the frame is not careless. The ActionForm interface itself does not require special implementation methods. It is used to identify the role of these specific Beans throughout the architecture. Typically, an actionform bean includes only attribute GET methods and SET methods, no business logic. Typically there is only a little input verification logic in an ActionForm Bean. The main reason for such beans is to save most of the recent value entered by the user-related form, so the same page can be rebuilt, with a set of error information, so that the user only needs to correct the wrong field. The authentication of the user input should be executed in the Action class (if it is very simple), or executes in the appropriate business logic beans. Define an attribute (with the associated getxxxx () and setxxxx () method) for each form. The field name and attribute name must match the JavaBeans agreement. For example, an input field called UserName will cause the setUserName () method being called. Below is the specific description of the Actionform class: Actionform class framery assumes that users create an actionform bean for each form in the application, for each of the beans defined in the struts-config.xml file, the framework is called the Action class Perform () The following operations are performed before: 1. In the associated keyword, it checks the user session for the Bean instance for the appropriate class. If there is no Bean available in the session, it will automatically create a new bean. And add to the user's session. 2. For each parameter corresponding to the bean property name, the Action calls the corresponding setting method. 3. When Action Perform () is called, the latest ActionForm bean is transmitted to it, and the parameter value can be used immediately. ActionForm class extension org.apache.struts.Action.Actionform class, the BEAN created by program developers can include additional properties, and ActionServlet may use reflection (allowing recycling information from loaded objects) to access it. The Actionform class provides another means of handling errors, providing two methods: public actionerrors validate (actionMappin mapping, servletRequest request) public actionerrors validate (actionMappin mapping, httpservletRequest request)
We should override the validate () method in our own, and set the validate of the
If you need to perform a specific data validity check, it is best to do this in the Action class, not in the ActionForm class.
Method RESET () can restore the properties of the bean to the default value:
Public Void Reset (ActionMapping Mapping, HttpservletRequest Request) Public Void Reset (ActionMapping Mapping, ServletRequest Request)
A typical actionFrom bean only has a method of setting with a read method (Getxxx) without transaction logic. Only simple input check logic, the purpose of use is to store the latest data entered in the relevant form so that the same web page can be regenerated while providing a set of error messages so that the user can modify the incorrect input data. It is really checking data validity to check the Action class or the appropriate transaction logic bean.
3, system status beans
The actual state of the system is usually expressed as a set of one or more JavaBean classes, which defines the current state. For example, in a shopping cart system, a bean indicating a shopping cart, which is maintained for each shopper, which includes the item entry selected by the shopper. Additionally, the system also includes saving user information, including their credit cards and delivery addresses, available entries and current inventory levels. These different beans.
For small-scale systems, or for status information that does not require long-term saving, a set of system status beans can contain information about specific details that have experienced by all systems. Alternatively, the system status bean will represent information permanently saved in some external databases (for example, the CustomerBean object corresponds to a specific row of data in the Customers table), creates or clears from the server's memory during need. Entity Enterprise JavaBeans is also for this purpose.
4, commercial logic beans
We should use the functional logic in the program to encapsulate the method call to JavaBean. These methods can be part of the system system architecture bean, or may be in a separate class specifically performing business logic. In the latter case, we usually need to pass the system status bean to these methods as parameters for processing.
In order to achieve the maximum reusability of code, business logic beans should be designed and implemented for them, do not know that they are executed in a web application environment. If found in our bean is in the type * class, we qualify this business logic in a web application environment. Consider reorganizing our Action class by calling the SET method for the business logic Beans attribute to translate all requested information from the HTTP request, then issue a call to the Execute method. This allows commercial logic classes to be reused in environments that were initially constructed.
Depending on our application's complexity and scope, business logic Beans can be a normal JavaBean that interacts with system status beans delivered as parameters, or is a normal JavaBean that uses JDBC access to the database. For larger applications, these beans are often state or stateless Enterprise JavaBeans (EJBs).
