DAO с пролетта и хибернацията

1. Общ преглед

Тази статия ще покаже как да внедрите DAO с Spring и Hibernate . За основната конфигурация на Hibernate вижте предишната статия Hibernate 5 с Spring.

2. Няма повече пролетни шаблони

От Spring 3.0 и Hibernate 3.0.1, Spring HibernateTemplate вече не е необходим за управление на Hibernate Session. Вече е възможно да се използват контекстни сесии - сесии, управлявани директно от Hibernate и активни в целия обхват на транзакция.

В резултат на това сега е най-добрата практика да се използва API за хибернация директно вместо HibernateTemplate. Това ефективно ще отдели напълно изпълнението на DAO слоя от Spring.

2.1. Превод на изключения без HibernateTemplate

Преводът на изключенията беше една от отговорностите на HibernateTemplate - превод на изключенията на Hibernate на ниско ниво на по-високо ниво, общи изключения на Spring.

Без шаблона този механизъм все още е активиран и активен за всички DAO, коментирани с анотацията @Repository . Под капака това използва постпроцесор на боб Spring, който ще съветва всички зърна @Repository с всички PersistenceExceptionTranslator, намерени в контекста на Spring.

Едно нещо, което трябва да запомните, е, че преводът на изключения използва прокси. За да може Spring да създава проксита около DAO класовете, те не трябва да се обявяват за окончателни .

2.2. Управление на сесия в хибернация без шаблон

Когато излезе поддръжката на Hibernate за контекстни сесии, HibernateTemplate по същество остаря. Всъщност Javadoc от класа сега подчертава този аспект (получер от оригинала):

ЗАБЕЛЕЖКА: От Hibernate 3.0.1 транзакционният код за достъп до Hibernate може също да бъде кодиран в обикновен стил на хибернация. Следователно, за новосъздадени проекти, помислете дали да не приемете стандартния стил Hibernate3 за кодиране на обекти за достъп до данни, базиран на {@link org.hibernate.SessionFactory # getCurrentSession ()}.

3. DAO

Ще започнем с основния DAO - абстрактен, параметризиран DAO, който поддържа общите родови операции и който можем да разширим за всеки обект:

public abstract class AbstractHibernateDAO{ private Class clazz; @Autowired private SessionFactory sessionFactory; public void setClazz(Class clazzToSet) { clazz = clazzToSet; } public T findOne(long id) { return (T) getCurrentSession().get( clazz, id ); } public List findAll() { return getCurrentSession() .createQuery( "from " + clazz.getName() ).list(); } public void save(T entity) { getCurrentSession().persist( entity ); } public T update(T entity) { return (T) getCurrentSession().merge( entity ); } public void delete(T entity) { getCurrentSession().delete( entity ); } public void deleteById(long id) { final T entity = findOne( id); delete( entity ); } protected final Session getCurrentSession(){ return sessionFactory.getCurrentSession(); } }

Няколко аспекта са интересни тук - както беше обсъдено, абстрактният DAO не разширява нито един пролетен шаблон (като HibernateTemplate ). Вместо това Hibernate SessionFactory се инжектира директно в DAO и ще играе ролята на основния API на Hibernate чрез контекстната сесия, която излага:

this.sessionFactory.getCurrentSession ();

Също така имайте предвид, че конструкторът получава Класа на обекта като параметър, който да се използва в общите операции.

Сега, нека разгледаме един пример за изпълнение на този DAO , за обект Foo :

@Repository public class FooDAO extends AbstractHibernateDAO implements IFooDAO{ public FooDAO(){ setClazz(Foo.class ); } }

4. Заключение

Тази статия обхваща конфигурацията и изпълнението на устойчивия слой с Hibernate и Spring.

Обсъдени бяха причините да се спре да се разчита на шаблони за слоя DAO, както и възможни клопки при конфигурирането на Spring за управление на транзакции и Hibernate Session. Крайният резултат е леко, изчистено изпълнение на DAO, почти без разчитане на времето за компилация на Spring.

Изпълнението на този прост проект може да бъде намерено в проекта github.