Prefacio
Como codificador dedicado al desarrollo de Java, la importancia de la primavera es evidente. Puede estar tratando con los marcos de primavera todos los días. La primavera se nombra, trayendo una comodidad de primavera al desarrollo de aplicaciones Java. Se puede decir que la primavera es una base necesaria para que cualquier desarrollador de Java llegue a la tecnología avanzada. Por supuesto, no es fácil aprender bien la primavera, especialmente para comprender los principios subyacentes de la primavera. Se necesitan mucho tiempo y energía para estudiarlo con cuidado, y constantemente juzgar y error y resumir en proyectos reales para formar su propio pensamiento y comprensión. El blogger tenía una comprensión muy superficial de la primavera al principio, y era posible confiar en el problema que Du Niang podría resolver de manera general al encontrar problemas en el proyecto. Sin embargo, durante más de un año desde que la primavera ha estado en contacto con la primavera, la comprensión de su sistema marco es bastante caótica, y la tecnología profunda sigue siendo como una niebla, y no ha formado su propia cognición y comprensión, lo que es muy desfavorable para la mejora de la tecnología de programación. En vista de esto, decidí calmarme y aprender el marco de primavera sistemáticamente de principio a fin, y registrar los detalles de aprendizaje y compartir el conocimiento técnico a través de la forma de un blog. Bien, vamos al punto
Introducción al marco de Spring Core
DI (inyección de dependencia), inyección de dependencia y otro concepto del que a menudo escuchamos, en realidad implementa las mismas funciones que el COI (inversión de control), pero las mismas funciones se explican desde diferentes perspectivas. El blogger aquí no irá a analizar demasiado, hay muchas explicaciones sobre Baidu. Lo que necesitamos saber es qué es la inyección de dependencia y por qué es la inyección de dependencia. Para comprender estos dos puntos, creo que aprender la primavera es la mejor en términos de pensamiento.
Cuando no se usa la primavera, es decir, cuando no hay inyección de dependencia, es difícil lograr una colaboración funcional mutua entre clases de aplicaciones Java. Si una determinada clase (a) necesita implementar sus funciones, si necesita confiar en la colaboración de otra clase (b), es necesario crear activamente un objeto de clase B en la Clase A para completar las funciones utilizando métodos de clase B (no debe preocuparse por los métodos estáticos y otras situaciones aquí). Esto es equivalente a que la Clase A sea responsable de la gestión de todo el ciclo de vida de los objetos de Clase B. En casos extremadamente simples, parece que no hay problema con los nuevos objetos de otra clase en una clase, pero la relación colaborativa entre clases y clases de aplicaciones complejas es a menudo multilateral. No sabemos en cuántos objetos alternativos dependerán de la implementación de una función de clase para cooperar. Por lo tanto, crear objetos en una clase y administrar todo el ciclo de vida del objeto causará un alto acoplamiento de código y complejidad inimaginable. Entonces, imagine que si podemos entregar el ciclo de vida de un objeto a un componente de terceros para la administración, y cuando una clase necesita otro objeto, el componente de terceros se creará directamente en él. De esta manera, la clase solo puede centrarse en la implementación de sus propias funciones sin administrar el ciclo de vida de otros objetos de clase, las funciones de tal clase son mucho más simples. Sí, debe haber entendido que Spring es este componente de terceros. Solo necesitamos decirle a Spring (Container) qué objetos deben ser manejados, y no tenemos que preocuparnos por cómo el marco de primavera crea objetos. De esta manera, cuando cierta clase A requiere objeto de clase B, si la clase B ha sido declarada y entregada a la gestión del contenedor de primavera, luego, cuando el programa se ejecuta a la Clase A y requiere la Clase B, el contenedor de primavera inyecta los objetos de Clase B en la Clase A a través de la inyección de dependencia para ayudar a completar las funciones comerciales. A través de la inyección de dependencia de componentes de terceros, los objetos ya no necesitan crear y gestionar dependencias entre las clases mismas. También hay muchas formas de crear inyección de dependencia de objetos, como inyección de interfaz, inyección del método de construcción, inyección del método de setter, etc. Hablando de esto, debe tener una comprensión relativamente directa de la inyección de dependencia. En cuanto a por qué se necesita la inyección de dependencia, el artículo anterior ya lo ha explicado muy claramente. Para reducir el acoplamiento entre los componentes en el código, primero debemos usar ejemplos simples para experimentar intuitivamente los beneficios de la inyección de dependencia sobre la gestión de objetos usted mismo -
El hombre de clase pública implementa humanos {auto qqcar privado; public Man () {this.car = new QqCar (); } @Override public void xiabibi () {} public void drivecar () {car.drive (); }}Hay dos implementaciones de Interface Car: Mercedes-Benz y QQ Car. En los códigos anteriores de Man y QqCar, el conductor veterano solo creó objetos de automóvil QQ a través del constructor, por lo que solo puede conducir el automóvil QQ. Entonces, ¿qué debe hacer el conductor veterano si quiere conducir Mercedes-Benz? ¿Le pides que recree el objeto Mercedes-Benz? Tal código altamente acoplado parece estar indefenso, por lo que haremos algunas mejoras en el código anterior inyectando objetos:
El hombre de clase pública implementa humanos {auto privado auto; hombre público (coche de coche) {this.car = car; } @Override public void xiabibi () {} public void drivecar () {car.drive (); }}El código anterior bloquea objetos específicos basados en características polimórficas a través de la inyección de la interfaz de constructor, para que los controladores veteranos puedan conducir lo que quieran. Este es el beneficio de la inyección de dependencia.
AOP (programación orientada al aspecto), programación orientada a la cara. En el desarrollo diario, cuando completamos una determinada función comercial, escribimos mucho código. Cuando finalmente optimizamos el código, encontramos que el código que realmente completa el negocio puede ser solo dos oraciones, y el resto no es muy relevante para esta parte del negocio. Se extrae por completo solo para implementar un cierto código de tecnología. Entonces, naturalmente, lo extraeremos en una clase de herramientas, para que todo lo que use esté bien con solo llamar al método de herramienta. Veamos un poco más alto. Además de completar las funciones comerciales relacionadas, los componentes funcionales de cada módulo comercial implican operaciones adicionales como registros, transacciones y control de seguridad. Estas no son las funciones centrales del módulo, pero son indispensables. Si estas funciones adicionales se agregan al código, cada componente del sistema comercial parecerá demasiado repetitivo y hará que el código comercial parezca confuso y no lo suficientemente puro. En este momento, le pregunta a Dios, ¿puede su código comercial centrarse solo en la implementación del negocio e ignorar cualquier cosa irrelevante como registros, transacciones, etc.? Oh, Dios dijo que estaba bien, así que había AOP. Si el propósito de la inyección de dependencia es mantener componentes cooperativos en un estado de acoplamiento relativamente flojo, AOP separa las funciones extendidas a través de la aplicación para formar componentes reutilizables. En términos de Layman, los registros, las transacciones, etc. son componentes reutilizables. Podemos extraer completamente los registros, transacciones, seguridad y otros códigos funcionales dispersos en varias partes del código de negocio y convertirnos en un componente de herramienta separado. Declararlo como una sección funcional en la configuración de Spring, y luego dígale a Spring dónde y cuándo desea usar (cortar) estos componentes reutilizables. Esta es mi simple interpretación de la sección orientada a la cara. Este artículo es solo una introducción, por lo que el blogger explicará brevemente el concepto y no hará implementaciones específicas de código o configuración. Se presentará en publicaciones de blog posteriores. Bienvenido a echar un vistazo.