Patterns in Spring Framework

The whole philosophy of Spring can be broadly categorized around five patterns that Spring adopts to do the job. The patterns are as follows:

• Ability to create Object
• Ability to build the relationship between objects.
• Callback and template mechanism
• Proxy Factory bean
• Exporter

Let's look into them

Ability to create Object

Ability to build the relationship between objects

This is covered in depth at Spring Introduction. The basic idea is that Spring will take the responsibility of creating objects and setting the relationship between objects.

Callback and Template Mechanism

This comes from the fact that Spring will take care of the boilerplate code and will let the application developer concentrate on the business logic part of the application. A typical implementation of this philosophy can be seen at Spring handling of data access layer including transactions at Spring Data Access. This can be seen in JMS handling also.

The basic idea is simple. All the code that is fixed and boilerplate in nature is taken care by the template. The developer is required to provide the business logic as part of callback, which is hooked to the template. For example, for fetching the data the template will take care of managing the connection, doing the query and iterating over the result set. The callback will take care of providing the business logic of handling each row. If the whole result set has to be processed in one go, then different kinds of templates are available.

Proxy Factory bean

Another pattern prevalent is of using Proxy factory beans. Especially used in remoting scenarios. For example, we need a service hosted in a JNDI. Then the proxy factory bean will act as a facade for the same and will take care of doing the lookups and fetching the service details. For other beans, this remoting service can be injected like any other dependency injection.

For example, if we have an account service hosted in a JNDI registry than we can use a type of proxy factory bean to fetch it and inject it into another service.

 <!-- Making a bean representing the remote service -->

<bean id="accountService" 

        class="org.springframework.remoting.rmi.RmiProxyFactoryBean">

    <property name="serviceUrl" 

               value="rmi://<HOST_NAME>:1099/AccountService"/>

    <property name="serviceInterface" 

               value="example.AccountService"/>

</bean>

<!-- Doing a dependency injection of remote service -->

<bean id="localService" class="com.lalit.LocalService">

   <property name="accountService" ref="accountService"/>

</bean>

Note that the local service has no idea that account service is a remote service.

Exporter

The other pattern is of exporting the services. This is used in situations like when Spring wants to expose its own services to outside systems. The exporter takes care of all the infrastructure details to take care of it.

Again take an example of JNDI and Spring wants to expose a service as a JNDI service.

<!--  Let's say we want to expose accountService on JNDI registry-->

<bean id="accountService" class="com.lalit.AccountServiceImpl">

<!-- other dependencies -->

</bean>

<!--Exporter will export the service taking care of all infrastructure-->

<bean class="org.springframework.remoting.rmi.RmiServiceExporter">

    <property name="serviceName" value="AccountService"/>

    <property name="service" ref="accountService"/>

   <property name="serviceInterface" value="com.lalit.AccountService"/>

   <property name="registryPort" value="1199"/>

</bean>

A thorough understanding of these five patterns, will help in learning Spring easily. Most of the Spring support for other things can be classified into one of the five ways that we have seen.

If you have found more patterns to this please put in the comment.

More Articles on Spring