Java Spring

Java Spring Framework

Sub-project

IoC, JDBC, MVC, AOP

Inversion of Control (IoC):

Dependency Injection: User do not create your objects manually, IoC container will instantiate required classes if needed.

  • Setter Injection

  • Constructor Injection:
    Injecting values to immutable fields and makes testing easier.

Bean :

Scope: Singleton(Not Thread- Safe)

Created By: IoC container

Life Cycle:

bean 工厂中bean 的生命周期/9项 当您在bean 工厂容器中加载bean时,它经过各种步骤,从它的实例化直到它的销毁。下图显示了bean 工厂容器中bean的生命周期。

在bean工厂中bean的生命周期期间执行了以下步骤: 1.实例化: 此步骤中,bean 工厂容器从XML 配置文件中提供的bean 定义实例化bean. 2.填充属性:在此步骤中,bean 工厂容器按照XML配置文件中所指定的通过DI填充所有bean 属性。 3.设置bean 名称: 在此步骤中,在创建bean 的bean工厂中设置bean 的名称。这是通过将bean 的ID 传递给BeanNameAware 接口提供的setBeanName() 方法来完成的。 4.设置bean 工厂: 在此步骤中,为bean 提供对管理它的bean工厂的引用。这是使用BeanFactoryAware 接口的setBeanFactory() 方法来完成的。 5.预初始化: 在此步骤中,您执行在初始化bean 之前需要完成的任务。这是通过在bean类中实现BeanPostProcessor 接口并定义其postProcessBeforeInitialization 方法来完成的。 6.初始化bean: 在此步骤中,您执行某些类型的初始化任务,然后bean 才可供使用。这些任务包括打开文件、打开网络或数据库连接以及分配内存。这是通过在bean 类中实现InitiallzingBean接口并定义其afterPropertiesSet ()方法来完成的。 7.初始化后: 在此步骤中,您执行在初始化bean之后需要完成的任务。这是通过在bean 类中实现BeanPostProcessor 接口并定义其postProcessAfterInitialization() 方法来完成的。 8.bean 可供使用: 此时,bean 已准各就绪,可供应用程序使用,将留在bean工厂中,直到应用程序不再需要它。 9.销毁bean: 在此步骤中,将销毁bean。如果bean实现DisposableBean 接口,将调用destroy () 方法。然而,如果为bean声明了自定义destroy方法,将调用该方法。

BeanFactory :

is an interface representing a container that provides and manages bean instances. The default implementation instantiates beans lazily when getBean() is called.

ApplicationContext

is an interface representing a container holding all information, metadata, and beans in the application. It also extends the BeanFactory interface but the default implementation instantiates beans eagerly when the application starts. This behavior can be overridden for individual beans.

Aspect Oriented Programming (AOP):

AOP: compliments OOPs in the sense that it also provides modularity. Example: Maintain log and send notification after calling methods

aspectj vs jdk:

cglib:

Problem without AOP: We can call methods (that maintains log and sends notification) from the methods starting with m. In such scenario, we need to write the code in all the 5 methods.

But, if client says in future, I don't have to send notification, you need to change all the methods. It leads to the maintenance problem.

Solution with AOP: We don't have to call methods from the method. Now we can define the additional concern like maintaining log, sending notification etc. in the method of a class. Its entry is given in the xml file.

In future, if client says to remove the notifier functionality, we need to change only in the xml file. So, maintenance is easy in AOP.

results matching ""

    No results matching ""