Remove descriptions of classic ORM API(JDO/JPA)
Issue: SPR-12987
This commit is contained in:
Kazuki Shimizu
parent
8853107f76
commit
91ac6fc716
|
|
@ -174,180 +174,6 @@ are simpler and more convenient for many scenarios.
|
|||
|
||||
|
||||
|
||||
[[classic-spring-jdo]]
|
||||
==== JDO
|
||||
For the currently recommended usage patterns for JDO see <<orm-jdo>>
|
||||
|
||||
|
||||
[[orm-jdo-template]]
|
||||
===== JdoTemplate and `JdoDaoSupport`
|
||||
|
||||
Each JDO-based DAO will then receive the `PersistenceManagerFactory` through dependency
|
||||
injection. Such a DAO could be coded against plain JDO API, working with the given
|
||||
`PersistenceManagerFactory`, but will usually rather be used with the Spring Framework's
|
||||
`JdoTemplate`:
|
||||
|
||||
[source,xml,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
<beans>
|
||||
|
||||
<bean id="myProductDao" class="product.ProductDaoImpl">
|
||||
<property name="persistenceManagerFactory" ref="myPmf"/>
|
||||
</bean>
|
||||
|
||||
</beans>
|
||||
----
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
public class ProductDaoImpl implements ProductDao {
|
||||
|
||||
private JdoTemplate jdoTemplate;
|
||||
|
||||
public void setPersistenceManagerFactory(PersistenceManagerFactory pmf) {
|
||||
this.jdoTemplate = new JdoTemplate(pmf);
|
||||
}
|
||||
|
||||
public Collection loadProductsByCategory(final String category) throws DataAccessException {
|
||||
return (Collection) this.jdoTemplate.execute(new JdoCallback() {
|
||||
public Object doInJdo(PersistenceManager pm) throws JDOException {
|
||||
Query query = pm.newQuery(Product.class, "category = pCategory");
|
||||
query.declareParameters("String pCategory");
|
||||
List result = query.execute(category);
|
||||
// do some further stuff with the result list
|
||||
return result;
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
}
|
||||
----
|
||||
|
||||
A callback implementation can effectively be used for any JDO data access. `JdoTemplate`
|
||||
will ensure that `PersistenceManager` s are properly opened and closed, and
|
||||
automatically participate in transactions. The template instances are thread-safe and
|
||||
reusable, they can thus be kept as instance variables of the surrounding class. For
|
||||
simple single-step actions such as a single `find`, `load`, `makePersistent`, or
|
||||
`delete` call, `JdoTemplate` offers alternative convenience methods that can replace
|
||||
such one line callback implementations. Furthermore, Spring provides a convenient
|
||||
`JdoDaoSupport` base class that provides a `setPersistenceManagerFactory(..)` method for
|
||||
receiving a `PersistenceManagerFactory`, and `getPersistenceManagerFactory()` and
|
||||
`getJdoTemplate()` for use by subclasses. In combination, this allows for very simple
|
||||
DAO implementations for typical requirements:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
public class ProductDaoImpl extends JdoDaoSupport implements ProductDao {
|
||||
|
||||
public Collection loadProductsByCategory(String category) throws DataAccessException {
|
||||
return getJdoTemplate().find(Product.class,
|
||||
"category = pCategory", "String category", new Object[] {category});
|
||||
}
|
||||
|
||||
}
|
||||
----
|
||||
|
||||
As alternative to working with Spring's `JdoTemplate`, you can also code Spring-based
|
||||
DAOs at the JDO API level, explicitly opening and closing a `PersistenceManager`. As
|
||||
elaborated in the corresponding Hibernate section, the main advantage of this approach
|
||||
is that your data access code is able to throw checked exceptions. `JdoDaoSupport`
|
||||
offers a variety of support methods for this scenario, for fetching and releasing a
|
||||
transactional `PersistenceManager` as well as for converting exceptions.
|
||||
|
||||
|
||||
|
||||
[[classic-spring-jpa]]
|
||||
==== JPA
|
||||
For the currently recommended usage patterns for JPA see <<orm-jpa>>
|
||||
|
||||
|
||||
[[orm-jpa-template]]
|
||||
===== JpaTemplate and `JpaDaoSupport`
|
||||
|
||||
Each JPA-based DAO will then receive a `EntityManagerFactory` via dependency injection.
|
||||
Such a DAO can be coded against plain JPA and work with the given `EntityManagerFactory`
|
||||
or through Spring's `JpaTemplate`:
|
||||
|
||||
[source,xml,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
<beans>
|
||||
|
||||
<bean id="myProductDao" class="product.ProductDaoImpl">
|
||||
<property name="entityManagerFactory" ref="myEmf"/>
|
||||
</bean>
|
||||
|
||||
</beans>
|
||||
----
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
public class JpaProductDao implements ProductDao {
|
||||
|
||||
private JpaTemplate jpaTemplate;
|
||||
|
||||
public void setEntityManagerFactory(EntityManagerFactory emf) {
|
||||
this.jpaTemplate = new JpaTemplate(emf);
|
||||
}
|
||||
|
||||
public Collection loadProductsByCategory(final String category) throws DataAccessException {
|
||||
return (Collection) this.jpaTemplate.execute(new JpaCallback() {
|
||||
public Object doInJpa(EntityManager em) throws PersistenceException {
|
||||
Query query = em.createQuery("from Product as p where p.category = :category");
|
||||
query.setParameter("category", category);
|
||||
List result = query.getResultList();
|
||||
// do some further processing with the result list
|
||||
return result;
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
}
|
||||
----
|
||||
|
||||
The `JpaCallback` implementation allows any type of JPA data access. The `JpaTemplate`
|
||||
will ensure that `EntityManager` s are properly opened and closed and automatically
|
||||
participate in transactions. Moreover, the `JpaTemplate` properly handles exceptions,
|
||||
making sure resources are cleaned up and the appropriate transactions rolled back. The
|
||||
template instances are thread-safe and reusable and they can be kept as instance
|
||||
variable of the enclosing class. Note that `JpaTemplate` offers single-step actions such
|
||||
as find, load, merge, etc along with alternative convenience methods that can replace
|
||||
one line callback implementations.
|
||||
|
||||
Furthermore, Spring provides a convenient `JpaDaoSupport` base class that provides the
|
||||
`get/setEntityManagerFactory` and `getJpaTemplate()` to be used by subclasses:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
public class ProductDaoImpl extends JpaDaoSupport implements ProductDao {
|
||||
|
||||
public Collection loadProductsByCategory(String category) throws DataAccessException {
|
||||
Map<String, String> params = new HashMap<String, String>();
|
||||
params.put("category", category);
|
||||
return getJpaTemplate().findByNamedParams("from Product as p where p.category = :category", params);
|
||||
}
|
||||
|
||||
}
|
||||
----
|
||||
|
||||
Besides working with Spring's `JpaTemplate`, one can also code Spring-based DAOs against
|
||||
the JPA, doing one's own explicit `EntityManager` handling. As also elaborated in the
|
||||
corresponding Hibernate section, the main advantage of this approach is that your data
|
||||
access code is able to throw checked exceptions. `JpaDaoSupport` offers a variety of
|
||||
support methods for this scenario, for retrieving and releasing a transaction
|
||||
`EntityManager`, as well as for converting exceptions.
|
||||
|
||||
__JpaTemplate mainly exists as a sibling of JdoTemplate and HibernateTemplate, offering
|
||||
the same style for people used to it.__
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[[classic-spring-jms]]
|
||||
=== JMS Usage
|
||||
|
|
|
|||
|
|
@ -5660,9 +5660,6 @@ example of a corresponding DAO implementation:
|
|||
}
|
||||
----
|
||||
|
||||
Because the above DAO follows the dependency injection pattern, it fits nicely into a
|
||||
Spring container, just as it would if coded against Spring's `JdoTemplate`:
|
||||
|
||||
[source,xml,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
----
|
||||
|
|
@ -5840,12 +5837,10 @@ JDO 2.0 implementations by default.
|
|||
[[orm-jdo-dialect]]
|
||||
==== JdoDialect
|
||||
|
||||
As an advanced feature, both `JdoTemplate` and `JdoTransactionManager` support a custom
|
||||
`JdoDialect` that can be passed into the `jdoDialect` bean property. In this scenario,
|
||||
the DAOs will not receive a `PersistenceManagerFactory` reference but rather a full
|
||||
`JdoTemplate` instance (for example, passed into the `jdoTemplate` property of
|
||||
`JdoDaoSupport`). Using a `JdoDialect` implementation, you can enable advanced features
|
||||
supported by Spring, usually in a vendor-specific manner:
|
||||
As an advanced feature, both `LocalPersistenceManagerFactoryBean` and `JdoTransactionManager`
|
||||
support a custom `JdoDialect` that can be passed into the `jdoDialect` bean property.
|
||||
Using a `JdoDialect` implementation, you can enable advanced features supported by Spring,
|
||||
usually in a vendor-specific manner:
|
||||
|
||||
* Applying specific transaction semantics such as custom isolation level or transaction
|
||||
timeout
|
||||
|
|
@ -6331,13 +6326,10 @@ the next section for details on the `JpaDialect` mechanism.
|
|||
[[orm-jpa-dialect]]
|
||||
==== JpaDialect
|
||||
|
||||
As an advanced feature `JpaTemplate`, `JpaTransactionManager` and subclasses of
|
||||
As an advanced feature `JpaTransactionManager` and subclasses of
|
||||
`AbstractEntityManagerFactoryBean` support a custom `JpaDialect`, to be passed into the
|
||||
`jpaDialect` bean property. In such a scenario, the DAOs do not receive an
|
||||
`EntityManagerFactory` reference but rather a full `JpaTemplate` instance (for example,
|
||||
passed into the `jpaTemplate` property of `JpaDaoSupport`). A `JpaDialect`
|
||||
implementation can enable some advanced features supported by Spring, usually in a
|
||||
vendor-specific manner:
|
||||
`jpaDialect` bean property. A `JpaDialect` implementation can enable some advanced
|
||||
features supported by Spring, usually in a vendor-specific manner:
|
||||
|
||||
* Applying specific transaction semantics such as custom isolation level or transaction
|
||||
timeout)
|
||||
|
|
|
|||
Loading…
Reference in New Issue