View the design mode from the Java class library (5)

With the foundation of many previous design patterns, a special pattern MVC can be proposed here. MVC does not belong to the 23 Design Patterns of gof, but it is proposed as an important example in the gof book and is highly appraised. Generally speaking, we think that the 23 gof models are intermediate ones, and some lower-layer models can be abstracted below them, you can also combine them to obtain some advanced modes. MVC can be seen as the result of combining some patterns (in fact, the emergence of MVC is earlier than the design pattern, but it is only analyzed on the basis of the design pattern ). Without the previous Foundation, it may be difficult to understand MVC.

MVC Mode

The MVC pattern is quite special. It has a wide range of meanings and involves more than just the design. It is difficult to simply classify it as the design pattern. Of course, it is mainly mentioned as a design concept, and MVC plays a vital role in the Java System. The Design Pattern in Java is mentioned here. Of course it is hard to pull it.

I will not talk about the ins and outs of MVC here. Here, the main s will talk about two aspects: MVC as the design pattern and MVC as the architecture pattern.

MVC refers to a method for dividing system functions. It divides a system into three parts:

Model: encapsulates the data source and all operations based on the data. In a component, the model often represents the component Status and Operation status.

View: encapsulates a display of the data source model. A model can be composed of multiple views, and a view can theoretically be associated with different models.

Control: encapsulates the operations performed on the model by the outside. Generally, these operations are forwarded to the model and one or more methods in the model are called. Generally, the Controller communicates between the model and view, processes user input on the view, and forwards it to the model. In this way, the model and view can be loosely coupled, or even unaware of each other, and the Controller connects the two parts.

With the many patterns described above, it is easy to explain the internal behavior of MVC through patterns. As mentioned above, in the design mode, MVC is actually a relatively high-level mode, which is composed of multiple basic design modes. The relationship between Model-View and Model-View is actually the observer mode, the model status and attempt display respond to each other, while view-controller is described by the Strategy Mode. View uses a specific controller instance to implement a specific response policy, if you change the controller, you can change the response of the view to user input. Some other design patterns can be easily combined into this system. For example, in composite mode, multiple views can be nested and combined. In factorymethod mode, the view controller can be specified.

The advantages of using MVC, on the one hand, separating data and its representation makes it easy to add or delete a user view, or even dynamically perform it during program execution. Model and view can be independently developed, increasing the maintainability and scalability of the program and making the test easier. On the other hand, the control logic and Presentation Interface are separated, allowing the program to dynamically select different user interfaces based on the workflow, user habits, or model status during running.

Swing claims to be completely designed according to the MVC idea. Before the design starts, swing hopes to achieve the following goals:

1. Model-driven programming.
2. Provides a single set of APIS, but supports a variety of looks-and-feel to provide users with different interfaces.

Naturally, we can find that using the MVC pattern can help achieve the above two goals.

Strictly speaking, MVC in swing is actually a variant of MVC: M-VC. Only the model interface is displayed in swing, and part of the view and controller mechanism is integrated in a UI object. View and control are loosely combined, and more control logic is introduced in the event listener part.

However, this does not prevent the embodiment of the essence of MVC in swing. In fact, at the initial stage of swing development, swing was indeed designed according to the standard MVC pattern, but the problem quickly emerged: View and controller are actually tightly coupled, it is difficult to make a general controller that can adapt to different views, and there is usually no need for it.

Basically, each component in swing has a corresponding model object. However, it does not have a one-to-one relationship. A model interface can serve multiple swing pairs. For example, jprogressbar, jscrollbar, and jslider all use the boundedrangemodel interface. The sharing of this model can reflect the connotation of MVC. In addition to the model interface, each swing component also contains a UI interface-View-controller, draws components and accepts user input.

Model-View is the relationship between subject and obverser. Therefore, changes to the model must be reflected in the UI object. Swing uses the event model of JavaBeans to implement this notification mechanism. Specifically, there are two implementation methods: one is to notify the event listener that the status has changed, and then the event listener extracts the necessary status information from the model. This mechanism is very effective for components with frequent events. Another method is to send a notification containing changed status information to the UI to the listener. The two methods are different components based on their advantages and disadvantages. For example, the first method is used in jscollbar, and the second method is used in jtable. To support multiple views, the model does not know each view. It maintains a list of obverser objects of interest to its data, so that every swing component object can be notified when the data changes.

The above is the MVC design pattern. In J2EE, Sun upgraded MVC to an architecture mode, and the meaning of MVC is more extensive. Unlike swing, the components of MVC here are no longer simple classes or interfaces, but an integral part of the application!

In J2EE blueprint, Sun recommends a MVC-based J2EE program mode. For enterprise distributed applications, it needs to support multiple forms of user interfaces. For example, online stores need an HTML interface to deal with online customers. WML interfaces can be provided to wireless users. Managers may need traditional swing-based applications for management, for business partners, XML-based Web services may be more convenient for them.

MVC is undoubtedly an effective solution to such a problem. By separating the core data access function from the control and display logic, a model module is formed to allow multiple views to share the model.

There are several core technologies in J2EE: JSP, JavaBean, Servlet, EJB, sessionbean, and entitybean constitute the cornerstone of J2EE architecture. JSP can generate HTML, WML, and even XML, which correspond to the view section in the Web application. As an intermediary between databases and applications, EJB provides data encapsulation. Generally, entitybean encapsulates data and sessionbean encapsulates data operations. These two parts are combined and correspond to the model part of the Web application. Technically, jsp can directly access ejbs, but this is not a good solution. It will confuse the display logic and control logic in the program, thus reducing the reuse performance of JSP. At this time, there are two solutions to access the data encapsulated by EJB through the control logic of the JavaBean or Servlet as the intermediary. In this case, the JavaBean or servlet corresponds to the Controller part of the Web reference program. The two types of controllers have their own advantages and disadvantages: The Interaction Between JSP and servlet is not easy to standardize, making the interaction process complex. However, servlet can interact with users separately, in fact, the running status of JSP is servlet. Due to the standardization of JavaBean, it is easy for JSP to interact with JavaBean. Using the get/Set Method of JavaBean, JSP can access data without too many statements, which allows JSP to focus on its view function to the maximum extent. Moreover, it is easy to use JavaBean in desktop applications, however, using Servlet is much more troublesome. Depending on the problem background, you can select different controllers. Sometimes you can use the two in combination or directly call JavaBean in the servlet.

In J2EE, MVC is a large framework. At this time, we often choose it not as a design pattern, but as an application of the architecture pattern.

Summary

In this article, I have analyzed some Java class libraries from the design point of view and focused on the use of design patterns. I believe that after reading this, you should have a deeper understanding of the Java class library itself and the design pattern. Of course, the Java class library is a very huge thing, and there are many well-designed structures. Therefore, the study of Java source code is very beneficial for coding and design. I have not been in touch with the design model for a long time, and may have some deviations in my understanding of it. If there are any mistakes, I suggest that you can discuss them together.

It should be noted that the model description is actually a set of complete specifications (or language), involving the model intent (intent), Problem description (problem ), context, force, solution, and resulting context. However, for the convenience of narration, they are not listed one by one. If you need to have a detailed study of the model, you should have a deeper understanding of these specifications.