Introduction
In the whole development process of Java EE, it is a very moment now. In many ways, Java EE was a great success: it succeeded in setting standards in places that had never been standard before, greatly increasing the openness of enterprise-class software and being widely recognized by the industry and developers alike. However, the Java EE has begun to be stretched in some ways. The cost of Java EE application development is usually very high. The Java EE Application project is at least as easy to fail as the previous non-Java project-if it is not more likely to fail. Such failure rates are unacceptably high. Under such a failure rate, software development has almost become a gamble. In the case of the Java EE encounter failure, EJB usually plays an important role. As a result, the Java EE community continues to evolve toward simpler solutions and less EJB use [1]. However, each application requires some infrastructure, and denying the use of EJBS does not mean rejecting the infrastructure solution used by the EJB. So how do you use the existing framework to provide these infrastructure services, and with this problem, a lightweight Java solution emerges, which is the spring framework.
Spring was born to simplify enterprise-level system development, and the spring Framework provides a simple, effective solution for Java EE to apply common problems, using spring, you can use simple Pojo (Plain old Java Object) To implement features that were previously only EJB-enabled. This will not only simplify server-side development, but any Java system development can benefit from the simple, testable, and loosely coupled features of spring. Simply put, spring is a lightweight, reverse-control (IoC) and aspect-oriented programming (AOP) container framework [3]. Spring IoC, with the aid of dependency injection design patterns, allows developers to ignore the lifecycle of the object itself and its relationships, and to improve the use of Java EE patterns by developers; Spring AOP, with the help of spring-enabled interceptors, Developers can implement declarative use of enterprise-level services, such as security services, transactional services, and so on. Spring IOC and Spring; The AOP portfolio, together with spring, is an organic whole that makes it possible to build lightweight Java EE architectures, and it turns out to be very effective. Spring AOP without spring IOC is imperfect, and spring IOC without spring AOP is not robust. This paper is based on the successful real Business system project of Spring Architecture, expounds the application of the reverse control principle and the aspect-oriented programming technology in the spring framework, simultaneously extracts the appropriate code to indicate the concrete application, and compares with the traditional development mode to show the spring framework's simple , efficient, maintainable and other advantages.
1. Spring IoC
1.1 Reverse Control principle
Reverse control is the core of the spring framework. But what does the reverse control mean? What is the reverse of the control? 2004 American expert Martin Fowler published a paper "inversion of control containers and" Dependency injection pattern, which explains the problem, He concluded that it was the reverse of the way to get the dependent object, and based on this revelation, he also proposed a more appropriate name for reverse control: Dependency Injection (DI dependency injection).
Typically, the application code needs to tell the container or framework to find the class that it needs, and then create the object instance to be used by the application code. Therefore, the application code needs to create an object instance before using the instance. However, in IOC mode, the task of creating an instance of an object is given to the IOC container or framework (the framework that implements the IOC design pattern is also called the IOC container), so that the application code needs only to use the instance directly, which is the IOC. In contrast to the IOC, "dependency injection" does more accurately describe the design concept. The so-called dependency injection, that is, the dependencies between components are determined by the container in the Run-time, the image, that is, the container dynamically injected a dependency into the component.
The implementation of 1.2 IOC in spring
Any important system requires at least two mutually cooperative classes to complete the business logic. Often, each object is responsible for its own cooperative (dependent) object. You will find that this leads to high code coupling and is difficult to test. With IOC, object dependencies are provided by external entities responsible for coordinating the objects in the system when the object is created, making it possible to loosely connect the software components. The following is a schematic of the spring IoC application, as follows:
(1) Define the action interface and define an Execute method for it to complete the destination logic. Many years ago, Gof in the book "Design pattern:elements of reusable object-oriented Software", the author of "Programming to a interface,not an Implementation "principle, here first to abstract business objects into interfaces, it is to implement this principle.
(2) class Upperaction implements the action interface, in this class, defines a string-type field message and provides the appropriate setter and getter methods to implement the Execute method as follows:
public string execute (String str) {
Return (GetMessage () + str). toUpperCase ();
}
(3) Write spring configuration file (bean.xml)
<beans>
<bean id="TheAction" class="net.chen.spring.qs.UpperAction">
<property name="message">
<value>HeLLo</value>
</property>
</bean>
</beans>