Quote a passage from the SPRING2.0 Technical manual:
The core of spring is a lightweight container that implements the IOC container and non-intrusive framework, provides a way to implement the AOP concept, provides support for persistence layers, transactions, provides implementations of the MVC Web Framework, and provides a consistent model encapsulation for some common enterprise service APIs, is a comprehensive application framework, and in addition to the various frameworks that exist, spring also provides a solution to integrate with them.
Next, I'll talk about some of my own understanding, the Spring Framework initiator before a very famous book name is probably "Java Development without EJB", He advocates the use of lightweight components instead of heavyweight EJBs. The author has not finished reading the book, only read some chapters. There is a point of analysis that makes sense:
There are web Container and EJB Container on the server side of the EJB, and the former view is that the layers should be physically isolated, the Web Container handle the View function, the business logic functions in the EJB Container, and then the EBJ container control of database persistence. This level is very clear, but a very serious problem is that the Web container and EJB container, after all, are two different containers, they need to communicate between the RMI mechanism and the JNDI service, but also on the server, but physically isolated, and is it necessary to call each business request remotely? It seems not that isolation is good.
Then look at the difference between lightweight and heavyweight, the author has seen many kinds of statements, that the most reasonable is the lightweight representative is POJO+IOC, the heavyweight representative is container+factory. (EJB2.0 is a typical technology for heavyweight components) We try to use lightweight pojo to understand that the meaning is compatibility and adaptability, and porting doesn't need to change the original code. Compared with factory, the IOC's advantage is greater flexibility, through configuration can control a lot of injection details, while the Factory mode, behavior is relatively closed fixed, the production of an object must accept its full characteristics, whether or not needed. In fact, lightweight and heavyweight are relative concepts, the use of less resources, running a smaller load of natural even light.
The topic is far away because the spring framework has brought too much to explore. For example, it's non-intrusive: it provides a framework implementation that allows programmers to program without feeling the framework, so the code is not tied to the frame and can be drawn out at any time, which is also the goal of spring design. Spring is the only thing that can really be programmed for interfaces, with interfaces everywhere, and not relying on binding to any implementation class. At the same time, Spring has designed its own MVC framework for transaction management, object management, and Model2, as well as other Java-EE services in which the idea of dependency injection and AOP is essentially used in implementation. So we can probably see what spring is a conceptual framework that represents a lot of good ideas that deserve to be studied in depth. The author emphasizes that learning is not a frame, but a frame of thought, just as we learned struts ...
1.Spring MVC
As for the IOC and AOP author has explained a little bit in the previous article, let's explore spring's features first through spring's MVC framework. (after all, most people are already familiar with struts, compare it)
It is well known that the core of MVC is the controller. Like the Actionservlet in struts, Spring inside the front-end controller is called Dispatcherservlet. The component that acts inside is called Controller, and the returned view Layer object is called Modelandview, and the component that is submitted and returned may be filtered. Interceptor.
Let's take a look at a process from request to return:
(1) foreground JSP or HTML by clicking Submit, loading the data into the request field
(2) The request is intercepted by the interceptor, executes the Prehandler () method to make the predecessor judgment
(3) Request arrives Dispathcerservlet
(4) Dispathcerservlet handler mapping to determine which back-end controller each reuqest should be forwarded to Controlle