SPRINGMVC prequel--from Struts 1.x-2.x mvc-spring 3.0 MVC

SPRINGMVC prequel--from Struts 1.x-2.x mvc-spring 3.0 MVC

http://downpour.iteye.com/blog/1330537

In our well-known Java EE application development based on the three-tier structure (presentation layer, business logic layer, persistence layer), the presentation layer has the most solutions. Because in the presentation layer of their own knowledge of many tentacles, there are a lot of problems to solve, which will inevitably result in the corresponding solutions.

In many discussions, I can often see the words "Such a frame is dead" or "a frame is already enough to defeat all other frameworks". in fact, each of these solutions has its own unique value and historical background. If you look at a framework from one aspect or the other, the comment is inevitably biased.

So, in the first article of the series, we take off the SPRINGMVC framework itself, put SPRINGMVC into a larger knowledge system, and talk about the development of the entire Web development domain, especially the MVC framework. Just as "knowing the history can see the future", when we can correctly examine the development of the whole MVC framework, we can analyze its development trend and stand at a higher level to evaluate all the solutions.

two types of models

Judging from the running structure of the whole B/s program, the presentation layer solution of the Java EE is actually an implementation of the "request-response" mode. Since the "request-response", there are bound to be two major communication roles:



Because the carrier and programming language implementations of these two roles are different, there are two distinct design ideas for the presentation layer solutions:

• Framework design with server-side application as the lead
• Frame design based on the browser page component (and its own event-triggering model)

The industry has also given different noun definitions to these two different design models: The former is called the MVC model , and the latter is called the component model , also known as the event model .

Note: I personally do not agree with the concept definition of these two models. Because in my personal opinion, the MVC model is defined in terms of the partitioning of programming elements, while the definition of the component model (event model) is the expression of dynamic interaction mode. So what we're emphasizing here is the difference in the benchmarks and priorities set by the solution itself.

From the user's community power, there is no doubt that the MVC model has gained more favor among programmers. There are many reasons for this, and we do not want to expand our discussion of the two different programming models here. Here, however, we will provide code examples based on the two programming models for the same business scenario (user registration) to help readers understand the different design ideas of the two programming models.

SPRINGMVC prequel--from Struts 1.x-2.x mvc-spring 3.0 MVC