POR QUÉ
Al comienzo de su nacimiento, el objetivo principal de crear primavera era reemplazar más tecnologías Java de nivel empresarial de peso pesado, especialmente EJB. En comparación con EJB, Spring proporciona un modelo de programación más ligero y simple.
QUÉ
Spring es un marco de código abierto creado por primera vez por Rodjohnson. Spring fue creado para resolver la complejidad del desarrollo de aplicaciones de nivel empresarial. El uso de Spring puede permitir que Javabeans simples implementen cosas que solo EJB podría lograr antes. Spring no se limita al desarrollo del lado del servidor, cualquier aplicación Java puede beneficiarse de Spring en términos de simplicidad, probabilidad y acoplamiento suelto.
Hoy Spring participa en el desarrollo móvil, la integración de API social, la base de datos NoSQL, la computación en la nube y los big data. Con el tiempo, EJB también adoptó los conceptos de inyección de dependencia (DI) y la programación orientada a los aspectos (AOP). En resumen, la misión más fundamental de Spring es simplificar el desarrollo de Java
CÓMO
Para reducir la complejidad del desarrollo de Java, Spring adopta una estrategia clave de 4 minutos
La programación invasiva ligera y mínima basada en POJO permite un acoplamiento suelto a través de la inyección de dependencia y orientado a la interfaz
La programación declarativa basada en secciones y convenciones reduce el código de estilo a través de secciones y plantillas
Potencial de pojo
Muchos marcos obligan a las aplicaciones a heredar sus clases o implementar sus interfaces, lo que hace que las aplicaciones estén vinculadas al marco, que es una programación invasiva, lo que resulta en la incapacidad de reutilizar los bloques de código. Spring se esfuerza por evitar estropear su código de aplicación debido a su propia API. En las aplicaciones construidas en la primavera, sus clases generalmente no tienen rastro de ningún signo que esté utilizando Spring.
clase pública HelloWorldBean {public String Sayshello () {return "Hello World"; }} El código de ejemplo anterior representa una clase Java muy simple y ordinaria (POJO). No se puede decir que es un componente de resorte. La programación no invasiva de Spring se refleja en esta clase que puede desempeñar un papel tanto en las aplicaciones de primavera como en las aplicaciones que no son de primavera. Solo esta pieza de código en realidad no refleja las funciones de Spring, y todavía se necesita el siguiente conocimiento.
Inyección de dependencia (inyectar la clase en sí dependiente)
La inyección de dependencia no es tan alta en primavera, aunque se ha convertido en una técnica de programación compleja o concepto de patrón de diseño. Esto se entiende en primavera, inyectando dependencias. Una aplicación con importancia práctica requiere múltiples clases para colaborar entre sí para completar la lógica comercial específica. La práctica tradicional es que cada objeto es responsable de administrar referencias a objetos relacionados con sí mismo (este objeto relacionado es el objeto que depende del objeto expresado en primavera), pero esto dificultará la prueba altamente acoplada y el código.
Considere el siguiente código
/** Este nombre de clase difícil de hacer fue nombrado especialmente por el autor para que se ajustara a una escena simulada* Esta clase representa al caballero que rescató a la niña* creada por Wung el 2016/8/25. */public class DamSeRescuingknight implementa Knight {private rescuedamselquest Quest;/*** creado rescuedamSelequest en su constructor* Esto hace damsescuescuing knight y rescuingdamSelQuest en su constructor acoplado*/public damelScuingknight () {this.Quest = New rescuedamSelquest ();} Public Void void EmbarkonQuest () {Quest.embark ();}} El acoplamiento tiene dos lados. Por un lado, el código estrechamente acoplado es difícil de probar, reutilizar y comprender, y habrá errores de tipo duende ". Por otro lado, es necesario un cierto grado de acoplamiento, y las diferentes clases deben interactuar de manera apropiada.
El problema surge, entonces, ¿cómo lo resolvió Spring?
En la primavera, a través de la inyección de dependencia (DI), las dependencias entre los objetos son establecidas por los componentes de terceros en el sistema que coordinan cada objeto al crear el objeto. En otras palabras, los objetos solo necesitan administrar sus propiedades internas sin crear o administrar sus dependencias por sí mismas, y las dependencias se inyectarán automáticamente en los objetos que los necesitan.
/*** Este caballero puede realizar varias tareas de aventura en lugar de solo la anterior para rescatar a la niña* creada por Wung el 2016/8/25. */public class Braveknight implementa Knight {private Quest Quest;/*** Braveknight no crea tipos de aventura por sí mismos, sino que pasa las tareas de aventura como parámetros durante la construcción* Esta es una de las formas de inyección de dependencia: inyección de constructor*/public Braveknight (Quest) {this.Quest = Quest;} Public Embarkonquest () {Quest.emark ();} ();};} Braveknight no se combina con ninguna implementación específica de misiones. Mientras una tarea implementa la interfaz de búsqueda, no importa qué tipo de aventura sea. Esto logra el propósito de un acoplamiento suelto
Si un objeto solo indica una dependencia a través de una interfaz, entonces esta dependencia puede reemplazarse con diferentes implementaciones concretas sin que el objeto mismo sea consciente.
Así que ahora, inyectemos un significado práctico
Para el código anterior, inyectaremos una tarea de aventura con una implementación específica en Brave Knight
/** La misión de aventura de Slaying Dragons (este autor es una buena clase de segunda clase)*creada por Wung el 2016/8/25. */public class SlayDragonQuest implements Quest {private printStream stream; public slaydragonQuest (printstream stream) {this.stream = stream;} public void empark () {stream.print ("slay the dragon");}}Entonces, ahora la pregunta es, cómo inyectar el objeto printstream del que depende en SlayDragonQuest, cómo inyectar el objeto de búsqueda del que depende en Braveknight. La primavera antes mencionada gestionará centralmente estas dependencias, y el comportamiento de crear colaboración entre los componentes de la aplicación generalmente se llama ensamblaje (cableado), es decir, inyección. Spring proporciona una variedad de métodos de ensamblaje para introducir con más detalle más adelante. Aquí presentamos brevemente el ensamblaje basado en XML y el ensamblaje basado en anotaciones Java.
<!- Este es un proceso de ensamblaje. Declare SlayDragonQuest como un frijol, llamado "Quest". Debido a que es una inyección de constructor, use el valor del atributo de constructor-arg para representar el valor inyectado. Este proceso resuelve el problema anterior. Inyecte el objeto PrintStream en el objeto SlayDragonQuest-> <Bean ID = "Quest"> <Constructor-Arg value = "#{t (System) .out}"> </ constructor-arg> </reme> <!-Este proceso es el mismo que el anterior. Braveknight declara un frijol llamado "caballero" (este nombre no se usa necesariamente), entonces el parámetro del constructor de Braveknight debe ser de tipo de búsqueda. En este momento, se pasa otro frijol en la referencia, que es la referencia del frijol con el nombre "Quest" anterior. En este momento, la inyección del constructor de Braveknight también se completa-> <bean id = "knight"> <constructor-arg ref = "Quest"> </ constructor-arg> </reme>Spring proporciona configuraciones basadas en Java que pueden usarse como alternativa a XML
/** El archivo de configuración basado en Java implementa el ensamblaje de objetos*creado por Wung el 2016/8/26. */ @ConfigurationPublic Class KnightConfig {@Bean Public Knight () {return new Braveknight (Quest ()); } @Bean Public Quest () {return New SlayDragonQuest (System.out); }}Los efectos son los mismos, y la explicación específica se describe en detalle en el próximo capítulo. Vamos a revisarlo de nuevo. Se ha dicho que Spring administrará automáticamente las dependencias entre objetos, entonces, ¿cuál es este tipo de gerente? La respuesta es el contexto de la aplicación, que es un contenedor para la primavera que puede cargar las definiciones de frijoles y ensamblarlas. El contexto de la aplicación Spring es el único responsable de la creación y el ensamblaje de objetos. De hecho, hay muchas formas de implementar la diferencia entre este contexto, solo la diferencia en la carga de la configuración. Veamos una forma de cargar la configuración.
public class KnightMain {public static void main (String [] args) {annotationConfigApplicationContext context = new AnnotationConfigApplicationContext (KnightConfig.Class); // La definición del bean se puede obtener del archivo de configuración. Knight Knight = context.getBean (Knight.class); Knight.embarkonquest (); context.close (); }}Aplicar corte facial
DI puede mantener componentes de software colaborativos acoplados libremente, mientras que la programación faceta le permite separar las funciones en toda la aplicación para formar componentes reutilizables y, más específicamente, es una tecnología que impulsa los sistemas de software para esforzarse por el enfoque. ¿Qué es un enfoque? Los servicios del sistema, como el registro, la gestión de transacciones y la gestión de seguridad, a menudo deben integrarse en otros componentes que tengan lógica comercial. Estos servicios del sistema generalmente se denominan enfoque transversal porque se reutilizarán en múltiples lugares, que abarcan múltiples componentes del sistema. En pocas palabras, extrae los servicios que deben reutilizarse de varios otros componentes, pero ¿cómo usarlos? De hecho, es insertar el método en los lugares que necesita usar al usarlo. Sin embargo, de acuerdo con este término "sección", debe expresarse como extraer el componente reutilizado como una sección, y cortar la sección a través del componente cuando sea necesario. Entonces, de esta manera, las aplicaciones centrales no necesitan conocer la existencia de estas secciones, y las secciones no integrarán la lógica comercial en las aplicaciones centrales.
/** Se utiliza una clase de cantante para alabar a los Caballeros, es decir, para servir a los Caballeros*creado por Wung el 2016/8/26. */public class Minstrel {private printStream Stream; Public MinStrel (PrintStream Stream) {this.stream = stream; } // ejecutar public void Singbeforequest () {stream.print ("begin"); } // ejecutar public void SingAfterquest () {stream.print ("end"); }} clase pública Braveknight implementa Knight {private Quest Quest; privado minstrel minstrel;/*** Braveknight no crea tipos de aventura por sí mismas, sino que pasa tareas de aventura como parámetros en la construcción* Esta es una de las formas de inyección de dependencia: inyección del constructor* /// Braveknight (Braveknight (Braveknight () {// this. MinStrel) {this.quest = Quest; this.minstrel = minStrel;} public void EmbarkonQuest () {minStrel.singBeForeQuest (); Quest.embark (); MinStrel.singAfterquest ();}} En este momento, el valiente caballero comenzó a ejecutarse, pero descubrió que en sus deberes no era solo un riesgo, sino que ahora tenía que manejar al cantante para alabarlo, pero esto en sí no debería pertenecer a la categoría que debería ser manejada. Por lo tanto, utilizando la idea de las secciones, necesitamos extraer el comportamiento de alabanza del cantante y convertirnos en una sección. Antes de que los Cavaliers corran el riesgo, esta sección se atravesará y ejecutará el método SingbeforeQuest y ejecutará el método SingAfterquest después del riesgo. Por lo tanto, esto se dará cuenta del código que no necesita ser alabado por el Caballero, y el cantante no existe en el objeto del Caballero. No solo alabará al Caballero, sino que también alabará a cualquiera siempre que otros usen esta sección para ingresar.
< Ejecución posterior a la nota antes y después del corte de punto de entrada-> </aop: después> </aop: antes> </aop: punto> </aop: </aop: config>
La situación es que Minstrel sigue siendo un POJO independiente, y el contexto de la primavera lo ha convertido en una sección. Lo más importante es que el Caballero no tiene idea de la existencia de esta sección en este momento. Esto es solo un pequeño castaño, que en realidad puede hacer muchas cosas importantes.
Use plantillas para eliminar el código de estilo
Hay una situación en la que cuando usamos JDBC para acceder a la base de datos para consultar datos, el proceso completo requiere establecer conexiones, crear objetos de declaración, procesar conjuntos de resultados, consultar y cerrar varias conexiones. Además, se capturan varias excepciones, y luego las consultas en varios escenarios requieren una repetición tan minuciosa. JDBC no es solo el único caso en el que hay mucho código de estilo como este. Spring tiene como objetivo eliminar el código de estilo a través de la encapsulación de la plantilla, como JDBCTemplate de Spring.
Acomoda tu frijoles
En aplicaciones basadas en primavera, sus objetos de aplicación viven en contenedores de primavera, que son responsables de crear objetos ensamblados objetos y administrar sus ciclos de vida. Entonces, ¿qué es el contenedor de primavera? No solo hay un tipo de contenedor. La primavera viene con múltiples implementaciones de contenedores. Se divide en dos categorías: fábricas de frijoles, que son los contenedores más simples para proporcionar soporte básico de DI. El contexto de la aplicación es relativamente avanzado y proporciona servicios de nivel de marco de aplicaciones. La mayoría de las veces, el contexto de la aplicación es más popular.
El contexto de la aplicación también se divide en muchas formas diferentes de cargar configuraciones.
Varias características de primavera
Resumir
Spring es una tecnología marco que puede simplificar el desarrollo, y su contenido principal es DI y AOP.
Lo anterior es el chisme sobre este artículo: entienda gradualmente todo el contenido de Spring, espero que sea útil para todos. Los amigos interesados pueden continuar referiéndose a este sitio:
Ejemplo de springmvc de inicio
Explicación detallada del código para inyectar el valor del atributo usando archivos de configuración y @Value en Spring
Spring Integrated Redis Sample de código detallado
Si hay alguna deficiencia, deje un mensaje para señalarlo.