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
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 boiler plate code and will let the application developer to 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 boiler plate in nature is taken care by the template. The developer are 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 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, than 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. Than 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 a 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 -->
<!-- Doing a dependency injection of remote service -->
<bean id="localService" class="com.lalit.LocalService">
<property name="accountService" ref="accountService"/>
Note that the local service has no idea that account service is a remote service.
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 -->
<!--Exporter will export the service taking care of all infrastructure-->
<property name="serviceName" value="AccountService"/>
<property name="service" ref="accountService"/>
<property name="serviceInterface" value="com.lalit.AccountService"/>
<property name="registryPort" value="1199"/>
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 a comment on this.
More Articles on Spring
More Articles on Spring