Why do we need the spring Framework?

One, why do we need the spring Framework? 1. From the Java-ee talkWhen the JDK 1.2 was published in 1998, the Standard Edition-J2SE, the Enterprise Edition-j2ee, the miniature version-j2me were published respectively. Java EE was born. At the Java One conference in 2005, Sun released all of the JDK 1.6,j2xx renamed JAVAXX,J2EE as Java EE. In March 2018, the Eclipse Foundation renamed Java EE as Jakarta EE. (Oracle will hand over Java EE to the open source organization Eclipse Foundation in 2017, but not allow it to continue to use the word JavaScript)

Java EE is a generic term for a technology system that includes: ejb-enterprise java Beans. Jndi-java naming and Directory Interface. Jdbc-java Database connectivity. Jms-java message Service. Servlet-java Servlet API. Jsp-java Server Pages. ... 2. Ejb-enterprise Java Bean

EJB is the core content of Java EE specification, and it is closely related to the birth of spring. EJB 2.0 was released in August 2001 and the EJB works as follows:

EJB provides a component pattern that allows developers to focus only on the development of system business, ignoring middleware requirements such as components, remote invocation, transaction management, persistence, and so on. Developers are free to add the required middleware services to the system when needed. At least on the surface, it's all very perfect and promising. But, you know, it's not really.

the problem with EJB.

Business classes need to be tightly coupled to the EJB framework, and multiple interfaces must be written to create business components

EJB 2.X requires that component interface interface and business logic implementation class classes must extend the interface from the EJB framework package , which creates a tight coupling between the code that the developer writes and the interface classes of the EJB framework. Incidentally, we also have to implement several unnecessary callback methods, such as Ejbcreate (), Ejbpassivate (), Ejbactivate (), ....

To develop an EJB component, developers need to write at least three different classes for the main program, the remote interface, and the business object:

/**
 * Remote interface enables clients to remotely invoke the business functions of the EJB
 component
/public interface Petservice extends Ejbobject {
    void Saveowner ( Owner owner) throws RemoteException
}
/**
 * Main interface allows the client to obtain the handle of the EJB
 component
/public interface Petservicehome extends EJBHome {
    Petservice Create () Throws RemoteException, createexception;
/**
 * Stateless session bean/
 Public
class Petservicebean implements Sessionbean {
    private sessioncontext Sessioncontext;

    The following methods implemented for EJB requirements are public

    void Ejbcreate () {} public void Ejbremote () {} public void

    ejbactivate (

    ) {} public void Ejbpassivate () {} public

    void Setsessioncontext (Sessioncontext sessioncontext) {
        This.sessioncontext = Sessioncontext;
    }

    /**
     * Business Method
     *
    /public void Saveowner () throws Java.rmi.RemoteException {
        //business code
    }
}

RMI brings unnecessary performance overhead. There is a servlet container and an EJB container at the same time in a Java server, and it is unacceptable that the servlet container must invoke the EJB through RMI. To avoid the RMI problem, EJB eventually introduced the local interface (remember "at least" in 1). ）。

Deployment requires lengthy XML deployment descriptors, which is not intuitive and error-prone.

It is difficult to unit test outside the container: The JNDI dependency lookup makes it difficult to unit test the component because of the dependency on the Jdni context.

Process oriented: The EJB programming model directs developers to a process-oriented programming style where data and behavior are separated rather than clustered together. The programming style is not debated here, except that we use Java as an object-oriented programming language, so we definitely want to take full advantage of Java, right? 3. POJO Programming Model

It is because of these problems that the EJB 2.X is gradually being hated by people. At the same time, the Pojo programming model, which is completely different from the EJB programming model, has been developed.

The word pojo-plain old Java Object was invented to describe the simplest classes that do not need to implement any particular interface or extend from a particular framework class. It also allows us to focus on writing code from an object-oriented perspective .

Our protagonist is here:

The Pojo programming model produces a number of frameworks in which the Spring framework is the most successful framework , and it has become the de facto standard framework for developing Java EE applications.

One thing to know is that most of the above problems have been solved in EJB 3.X, but the spring Framework has grown in the past. In addition, the most important point in all of the EJB improvements is that the EJB specification introduces the POJO programming model. Obviously, this is largely due to the impact of the spring Framework. In addition, the current spring Framework is already compatible with many EJB specifications. For example: @Resource, @PostConstruct, @PreDestroy. 4. Summary: Why do we need the spring Framework.

In the historical time period of EJB 2.X, due to its own design problems, the use of the EJB model to develop increased complexity, the most important problem is that the business class needs to be tightly coupled with the EJB framework .

The spring Framework, which was born on this time node, provides us with a simpler and more easy-to-use option. Business code is pure, our business code does not have to rely on the APIs of the services in the framework, and these services are pluggable. (Business code Pure, service pluggable) second, what the Spring Framework brings to us.

In 2002, Rod Johnson published the first version of the spring Framework in the book expert one-on-one Java EE design and Development.

Later he released the expert one-on-one Java Development without EJB

and the professional Java Development with the Spring Framework

The Spring Framework brings us a lightweight container that allows us to write business code without being "hacked". 1. Lightweight containers

Container for Java EE

In Java EE, there is a "container" concept, which refers to an environment in which all components are created and assembled, and the required middleware services are provided.

Java EE provides a number of containers:

The Servlet container is responsible for creating and managing Web-tier components

such as Servlet, JSP, Filter.

EJB containers focus on the business layer

Manage EJB components.

Lightweight containers

Any container should provide some basic services to the components it manages. According to the expert one-on-one Java Development without EJB book, you can list some of the expected services described below: Lifecycle Management Dependency resolution component lookup application configuration

If you can further provide some middleware services, it would be better: Transaction management thread Management objects and resource pools extend and customize the component's Remote access container

A lightweight container (lightweight container) contains all of these features, but you don't need to rely on those APIs to write code. In other words, lightweight containers are not intrusive, and theSpring Framework is the most famous lightweight container in the Enterprise Java World. 2. Control reversal

The most important benefit provided by the container and its managed components is the pluggable architecture . Components need to implement some interfaces and can access services provided by other components through a similar interface. Components do not need to know the specific implementation classes of these services, so implementations are easy to replace. The work of the container is to create these components and the services on which they depend, and assemble the components together .

control inversion : In the Component class, the component does not need to instantiate other components on which it relies, but instead injects the dependent component into the component at run time. This pattern is referred to as control reversal (inversion of controll), called the IOC, where control over dependency is reversed by the component itself to the container .

IoC is the basic function that any container has to offer, and it has two main implementations: Dependency lookup (Dependency lookup) and Dependency injection (Dependency injection):

Dependency Lookup

The container provides a callback method to the component it manages, and the component explicitly acquires the dependencies it needs through the callback method. You typically use a find context to access dependent components.

Dependency Injection

The component must provide an appropriate constructor or setter method so that the container can inject additional components that it relies on for the component.

In the original Java EE, the main method used is to rely on lookup, the "lookup context" mentioned above is Jndi. With the advent of many lightweight containers such as the spring Framework, Dependency injection became popular. Today, when developers refer to IOC again, they are often interpreted as dependency injection. 3. Dependency Injection

The basic principle of dependency injection is that application objects should not be responsible for locating the resources on which they depend, but rather that the IOC container handles the creation and dependency injection of objects.

A good container should support both constructor injection and setter injection.

Setter Injection

When an object is instantiated, its setter method is called immediately.

Advantages

After a component is configured, it can be reconfigured at run time because the setter method itself is the content of the JavaBean specification, so the external world can also modify its dependent values later.

Disadvantages

It is possible that not all dependencies can be injected before use, so that the component is in a partial configuration state (Setter loop dependent). Because the order of the setter cannot be agreed in the Assembly, it can result in state inconsistency.

Constructor injection

Advantages

Each managed component is in a consistent state (circular dependencies can have a direct error) and can be used immediately after it is created.

Disadvantages

Components cannot be reconfigured after the component has been created.

In actual use, we usually mix the two injection methods.

Above, we know why the spring Framework is used. "And what the spring Framework brings to us.