Introducción y uso del marco básico de Spring

Modularidad.

La evolución de la primavera

Arquitectura de aplicación única

Cuando el tráfico del sitio web es muy pequeño, solo se necesita una aplicación y todas las funciones se implementan juntas para reducir los nodos y los costos de implementación. En este momento, el marco de acceso a datos (ORM) utilizado para simplificar la carga de trabajo de agregar, eliminar, modificar y verificar es la clave.

Arquitectura de aplicación vertical

Cuando el número de visitas aumenta gradualmente, la aceleración causada por la adición de una sola aplicación a la máquina se vuelve cada vez más pequeña Una de las formas de mejorar la eficiencia es dividir la aplicación en varias aplicaciones no relacionadas para mejorar la eficiencia. En este momento, el marco web (MVC) que se utiliza para acelerar el desarrollo de las páginas frontales es la clave.

Arquitectura de servicios distribuidos

Cuando hay más y más aplicaciones verticales, la interacción entre aplicaciones es inevitable. El negocio principal se extrae como un servicio independiente y se forma gradualmente un centro de servicio estable, de modo que las aplicaciones front-end puedan responder más rápidamente a las cambiantes demandas del mercado. En este momento, el marco de servicio distribuido (RPC) para mejorar la integración y la reutilización empresarial es la clave.

Arquitectura informática móvil

Cuando hay más y más servicios, aparece gradualmente la evaluación de la capacidad y el desperdicio de pequeños recursos de servicio. En este momento, es necesario agregar un centro de despacho para administrar la capacidad del clúster en tiempo real en función de la presión de acceso para mejorar el clúster utilización. En este momento, el centro de programación y gobernanza de recursos (SOA) utilizado para mejorar la utilización de la máquina es la clave.

La evolución del marco principal de Java

1 、 JSP + Servlet (servidor + subprograma) + JavaBean

jsp se puede incrustar directamente en el código java

2, arquitectura MVC de tres niveles

Capas DAO: entidad, frijol, po, vo, bo, pojo

3. Use EJB para el desarrollo de aplicaciones, pero EJB es un marco de trabajo pesado (cuando se usa, hay demasiadas interfaces y dependencias, y es muy intrusivo), que es más problemático de usar.

4 、 Struts1 / Struts2 + Hibernate + Spring

5 、 PrimaveraMVC + Mybatis + Primavera

6, desarrollo SpringBoot, el acuerdo es mayor que la configuración

Explicación básica

Spring es un marco de código abierto.
Spring nació para simplificar el desarrollo empresarial, haciendo que el desarrollo sea más elegante y conciso.
Spring es un marco de contenedores para IOC y AOP .
COI: Inversión de control
AOP: programación orientada a aspectos
Contenedor: contiene y administra el ciclo de vida de los objetos de la aplicación, al igual que cuando se usa un balde de agua, el manantial es un balde y el objeto es agua.

Ventajas de usar resorte

1. Spring simplifica el desarrollo de Java a nivel empresarial mediante DI, AOP y la eliminación del código repetitivo
2. Además del marco Spring, existe un enorme ecosistema construido sobre el marco central, que extiende Spring a diferentes campos, como servicios web, REST, desarrollo móvil y NoSQL.
3. Diseño de baja intrusión, la contaminación del código es extremadamente baja
4. Independientemente de varios servidores de aplicaciones, las aplicaciones basadas en el marco de Spring pueden realmente realizar la promesa de Write Once, Run Anywhere
5. El contenedor de IoC de Spring reduce la complejidad del reemplazo de objetos comerciales y mejora el desacoplamiento entre componentes
6. El soporte AOP de Spring permite el procesamiento centralizado de algunas tareas comunes como seguridad, transacciones, registros, etc., proporcionando así una mejor reutilización.
7. ORM y DAO de Spring proporcionan una buena integración con marcos de capa de persistencia de terceros y simplifican el acceso a la base de datos subyacente.
8. El alto grado de apertura de Spring no obliga a las aplicaciones a depender completamente de Spring. Los desarrolladores son libres de elegir parte o todo el marco de Spring.

3. IOC (Inversión de control): Inversión de control

Por qué presentar la COI

Cree un proyecto java ordinario para completar las siguientes funciones

UserDao.java

package com.mashibing.dao;

public interface UserDao {
    public void getUser();
}

UserDaoImpl.java

package com.mashibing.dao.impl;

import com.mashibing.dao.UserDao;

public class UserDaoImpl  implements UserDao {
    @Override
    public void getUser() {
        System.out.println("获取用户数据");
    }
}

UserService.java

package com.mashibing.service;

public interface UserService {
    public void getUser();
}

UserServiceImpl.java

package com.mashibing.service.impl;

import com.mashibing.dao.UserDao;
import com.mashibing.dao.impl.UserDaoImpl;
import com.mashibing.dao.impl.UserDaoMysqlImpl;
import com.mashibing.service.UserService;

public class UserServiceImpl implements UserService {

    private UserDao userDao = new UserDaoImpl();

    @Override
    public void getUser() {
        userDao.getUser();
    }
}

SpringDemoTest.java

package com.mashibing.test;

import com.mashibing.service.UserService;
import com.mashibing.service.impl.UserServiceImpl;

public class SpringDemoTest {
    public static void main(String[] args) {
       UserService service = new UserServiceImpl();
       service.getUser();
    }
}

En el proceso de escritura de código anterior, todos completamos nuestras funciones de esta manera, pero ¿qué pasa si agregamos una clase de implementación UserDao?

UserDaoMysqlImpl.java

package com.mashibing.dao.impl;

import com.mashibing.dao.UserDao;

public class UserDaoMysqlImpl implements UserDao {
    @Override
    public void getUser() {
        System.out.println("mysql");
    }
}

Si queremos usar mysql, entonces debemos modificar el código de UserServiceImpl.java:

package com.mashibing.service.impl;

import com.mashibing.dao.UserDao;
import com.mashibing.dao.impl.UserDaoImpl;
import com.mashibing.dao.impl.UserDaoMysqlImpl;
import com.mashibing.service.UserService;

public class UserServiceImpl implements UserService {

    private UserDao userDao = new UserDaoImpl();

    @Override
    public void getUser() {
        userDao.getUser();
    }
}

Pero, ¿y si agregamos otra clase de oráculo?

UserDaoOracleImpl.java

package com.mashibing.dao.impl;

import com.mashibing.dao.UserDao;

public class UserDaoOracleImpl implements UserDao {
    @Override
    public void getUser() {
        System.out.println("oracle");
    }
}

En este momento, UserService todavía tiene que seguir modificando. Obviamente, este método ya no es adecuado para nuestras necesidades, así que cómo solucionarlo, puede utilizar lo siguiente

UserServiceImpl.java

package com.mashibing.service.impl;

import com.mashibing.dao.UserDao;
import com.mashibing.dao.impl.UserDaoImpl;
import com.mashibing.service.UserService;

public class UserServiceImpl implements UserService {
    private UserDao userDao;

    public void setUserDao(UserDao userDao){
        this.userDao = userDao;
    }
    @Override
    public void getUser() {
        userDao.getUser();
    }
}

Clase de prueba SpringDemoTest.java

package com.mashibing.test;

import com.mashibing.dao.impl.UserDaoMysqlImpl;
import com.mashibing.dao.impl.UserDaoOracleImpl;
import com.mashibing.service.UserService;
import com.mashibing.service.impl.UserServiceImpl;

public class SpringDemoTest {
    public static void main(String[] args) {
        UserServiceImpl userService = new UserServiceImpl();
        userService.setUserDao(new UserDaoMysqlImpl());
        userService.getUser();

        userService.setUserDao(new UserDaoOracleImpl());
        userService.getUser();
    }
}

De hecho, a partir del código de ahora, todos deberían poder apreciar la importancia del desacoplamiento.Ahora comenzaremos a aprender el IOC de Spring.

Inicial del COI

Ioc es una especie de pensamiento, DI es la forma de implementación ( IOC y DI describen lo mismo desde diferentes perspectivas, IOC se describe desde la perspectiva del contenedor y DI se describe desde la perspectiva de la aplicación )

Si desea comprender la COI, debe aclarar las siguientes preguntas:

1. Quién controla a quién
2. Controla qué
3. Qué es la reversión
4. Qué aspectos se invierten

Si este proceso es más difícil de entender, entonces puede imaginarse el proceso de encontrar una novia y una empresa de emparejamiento. Si se puede entender este proceso, ahora responderemos las preguntas anteriores:

1. Quién controla quién: En el proceso de codificación anterior, se necesitaban todos los objetos para crear qué objetos ellos mismos, y los programadores controlaban los objetos mismos. Con el contenedor IOC, se convertirá en el contenedor IOC para controlar el objeto.
2. Qué para controlar: los objetos necesarios en el proceso de implementación y los objetos en los que se debe confiar.
3. Qué es la inversión: antes de que no existiera el contenedor IOC, todos creábamos activamente objetos dependientes en el objeto. Esta es una rotación hacia adelante, y Después del COI, los objetos dependientes son creados directamente por el contenedor del COI y se inyectan en los objetos, desde la creación activa hasta la aceptación pasiva. Esta es la inversión
4. Qué aspectos se invierten: objetos dependientes

concepto basico

IoC también se conoce como inyección de dependencia (DI). Es un proceso mediante el cual los objetos definen sus dependencias (es decir, los otros objetos con los que trabajan) solo a través de argumentos de constructor, argumentos para un método de fábrica o propiedades que se establecen en la instancia del objeto después de que se construye o devuelve desde un método de fábrica. . El contenedor luego inyecta esas dependencias cuando crea el bean. Este proceso es fundamentalmente el inverso (de ahí el nombre, Inversión de control) del propio bean que controla la instanciación o ubicación de sus dependencias mediante la construcción directa de clases o un mecanismo como el patrón Service Locator.
IOC es similar a la conocida inyección de dependencia. Este es un proceso de inyección de objetos a través de la dependencia. Es decir, los objetos que utilizan son a través de los parámetros del constructor, los parámetros del método de fábrica o esto es del constructor del método de fábrica o el conjunto de propiedades. por la instancia de objeto del valor de retorno, y luego el contenedor inyecta estas dependencias requeridas al crear el bean. Este proceso es inverso al proceso normal de creación de objetos (de ahí el nombre de IoC). El propio bean controla la instanciación o ubicación de las dependencias mediante la construcción directa de clases, o proporciona mecanismos como el patrón de localización de servicios.

EN 与 COI

Mucha gente dice que IOC y DI son lo mismo. En general, no hay problema, pero hay una diferencia en esencia. Espero que todos puedan ser más rigurosos. IOC y DI describen lo mismo desde diferentes ángulos. IOC Es se describe desde la perspectiva del contenedor, mientras que DI se describe desde la perspectiva de la aplicación. También se puede decir que IOC es la idea de diseño y DI es la implementación específica

4. Resumen

En el resumen aquí, espero que pueda entender dos cosas:

1, desacoplamiento

En un sistema de software de diseño orientado a objetos, la implementación subyacente se compone de N objetos, y todos los objetos cooperan entre sí para finalmente realizar la lógica empresarial del sistema.

Cabe señalar que en una relación de combinación de este tipo, una vez que un determinado objeto tiene un problema, otros objetos deben verse afectados, ya que el acoplamiento es demasiado alto, pero la relación de acoplamiento de los objetos es inevitable. A medida que las aplicaciones se hacen más y más grandes, el acoplamiento de objetos puede volverse cada vez más complejo y, a menudo, se requieren múltiples dependencias. Por lo tanto, tanto los arquitectos como los programadores deben reducir el acoplamiento de estos objetos cuando se enfrentan a tales escenarios.

La relación de acoplamiento no es solo entre el objeto y el objeto, sino también entre los distintos módulos del sistema de software, es un problema en el que debemos centrarnos. Para resolver el problema del acoplamiento excesivo entre objetos, podemos lograr el desacoplamiento entre objetos a través de IOC. El marco de resorte es la aplicación más utilizada de la teoría de IOC.

Como puede ver en la figura anterior, cuando se introduce un contenedor de terceros, no existe una relación de acoplamiento entre varios objetos. Todos los objetos están controlados por el contenedor. Este contenedor es equivalente al adhesivo, que hará que los objetos se peguen entre sí. interpretar un papel.

2, ecológico

Si algún lenguaje o cualquier marco quiere ser invencible, lo más importante es su ecología.