2008-09-28 09:57 <! - The definition of Transaction Manager (Declarative Services) ->
<bean
>
<property name="sessionFactory">
<ref local="sessionFactory" />
</ property>
</ bean>

<! - Business Logic Tier (DAO for each layer are positive package) the principal use <<window-mode>> ->
<bean
>
<property name="operdao">
<ref bean="operatorDAO" />
</ property>
<property name="producedao">
<ref bean="fundProduceDAO" />
</ property>
<property name="customerdao">
<ref bean="customerDAO" />
</ property>
<property name="accountdao">
<ref bean="accountDAO" />
</ property>
<property name="fundaccountdao">
<ref bean="fundAccountDAO" />
</ property>
<property name="fundtransdao">
<ref bean="fundTransDAO" />
</ property>
</ bean>

There may be many other modules. <bean/> may just be one of the modules.

The first is: Declarative configuration services as follows. Is our most commonly used method, and it applies to your database table is less the case.

<bean
>
<! - Configure the transaction manager ->
<property name="transactionManager">
<ref bean="transactionManager" />
</ property>
<! - This property specify whether the target category of the province are the target agent. If the target type did not achieve any category, it is set to true representatives of their own ->
<property name="proxyTargetClass">
<value> false </ value>
</ property>
<property name="proxyInterfaces">
<value> com.jack.fund.service.IFundService </ value>
</ property>
<! - The target bean ->
<property name="target">
<ref bean="fundService" />
</ property>
<! - Configure Services property ->
<property name="transactionAttributes">
<props>
<prop key="delete*"> PROPAGATION_REQUIRED </ prop>
<prop key="add*"> PROPAGATION_REQUIRED </ prop>
<prop key="update*"> PROPAGATION_REQUIRED </ prop>
<prop key="save*"> PROPAGATION_REQUIRED </ prop>
<prop key="find*"> PROPAGATION_REQUIRED, readOnly </ prop>
</ props>
</ property>
</ bean>
Below there may be other xxxServiceDAOProxy. Everyone can see that for each function module to configure a business service agent. If many modules lying, it becomes a bit more code and found that they are only slightly different. At this time we should think of the idea of succession. The second method used.

The second: Declarative configuration services as follows. This situation is relatively suitable to use many modules.

<! - The idea to use inheritance to simplify configuration, we should abstract = "true" ->
<bean

lazy-init = "true" abstract = "true">
<! - Configure the transaction manager ->
<property name="transactionManager">
<ref bean="transactionManager" />
</ property>
<! - Configure Services property ->
<property name="transactionAttributes">
<props>
<prop key="delete*"> PROPAGATION_REQUIRED </ prop>
<prop key="add*"> PROPAGATION_REQUIRED </ prop>
<prop key="update*"> PROPAGATION_REQUIRED </ prop>
<prop key="save*"> PROPAGATION_REQUIRED </ prop>
<prop key="find*"> PROPAGATION_REQUIRED, readOnly </ prop>
</ props>
</ property>
</ bean>
And specific modules can be configured so simple.
As long as specified in its parent (parent class) in relation to it.
Parent generally put abstract = "true", because the container is loaded at the time does not need initialization, when no longer used until it has a sub-category called when the initialization again.
<bean parent="transactionBase">
<property name="target">
<ref bean="fundService" />
</ property>
</ bean>
This configuration, if there are multiple modules such as fundService can be much less duplicate code.

The third: Declarative configuration services as follows. The main use of BeanNameAutoProxyCreator automatically create Service agent

<bean
>
<property name="transactionManager">
<ref bean="transactionManager" />
</ property>
<! - Configure Services property ->
<property name="transactionAttributes">
<props>
<prop key="delete*"> PROPAGATION_REQUIRED </ prop>
<prop key="add*"> PROPAGATION_REQUIRED </ prop>
<prop key="update*"> PROPAGATION_REQUIRED </ prop>
<prop key="save*"> PROPAGATION_REQUIRED </ prop>
<prop key="find*"> PROPAGATION_REQUIRED, readOnly </ prop>
</ props>
</ property>
</ bean>

<bean
>
<property name="beanNames">
<list>
<value> fundService </ value>
</ list>
</ property>
<property name="interceptorNames">
<list>
<value> transactionInterceptor </ value>
</ list>
</ property>
</ bean>
The main advantage of this method the principle of interceptors.

The former three methods are generally required to designate a specific module bean.
If the module too much so, such as a large site in general has dozens of modules, we have to consider the allocation of the fourth. Automatic creation of affairs the way the agent.

The fourth: Declarative configuration services as follows.

<bean
>
<property name="transactionManager">
<ref bean="transactionManager" />
</ property>
</ bean>

<! - Automatic agent ->
<bean
>
<! - Could be the Service or the DAO layer (it is best for the business layer * Service) ->
<property name="beanNames">
<list>
<value> * Service </ value>
</ list>
</ property>
<property name="interceptorNames">
<list>
<value> transactionInterceptor </ value>
</ list>
</ property>
</ bean>

There is also a usage of automated agent is combined with regular expressions and the advice to use.

<bean
>
<property name="transactionManager">
<ref bean="transactionManager" />
</ property>
</ bean>

<bean
>
</ bean>

<bean
>
<property name="advice">
<ref bean="transactionInterceptor" />
</ property>
<property name="pattern">
<value> .* </ value>
</ property>
</ bean>

This method-specific modules can intercept and handle affairs.

In your actual project, you can choose according to your different methods.