Трехуровневое приложение с использованием Wicket + Spring + Hibernate. Как бы вы обрабатывали транзакции?

Question

Я подумываю об использовании Open Session In View (OSIV) фильтра или перехватчика, который поставляется с Spring, так как это кажется мне удобным способом для разработчика. Если это то, что вы рекомендуете, вы рекомендуете использовать фильтр или перехватчик и почему?

Мне также интересно, как он будет смешиваться с HibernateTemplate , и если я потеряю способность помечать методы как @ Transactional (readOnly = true) и т. Д. И таким образом терю способность получить более детальный контроль транзакций?

Существует ли какая-то лучшая практика для интеграции этого вида решения с трехуровневой архитектурой с использованием Hibernate и Spring (как я полагаю, мое решение использовать Wicket для презентации не должно иметь большого значения) *

Если я использую OSIV, я, по крайней мере, никогда не столкнусь с отложенными загрузочными исключениями, с другой стороны, моя транзакция будет жить дольше, прежде чем сможет зафиксироваться, будучи также незафиксированной в представлении.

Answer 1

Это действительно вопрос личного вкуса.

Лично мне нравится иметь границы транзакций на уровне сервиса. Если вы начинаете думать о SOA, каждый вызов службы должен быть независимым. Если ваш уровень представления должен вызывать 2 разные службы (мы можем утверждать, что это уже запах кода), тогда эти две службы должны вести себя независимо друг от друга, могут иметь разные конфигурации транзакций и т. Д. Не имея открытых транзакций вне Службы также помогают убедиться, что за пределами службы не происходит никаких изменений.

OTOH вам придется подумать немного больше о том, что вы делаете в своих сервисах (ленивая загрузка, группировка функций в одном и том же методе сервиса, если им нужна общая транзакция и т. Д.).

Один шаблон, который может помочь уменьшить ошибку отложенной загрузки, - это использовать Value Object вне уровня обслуживания. Службы должны всегда загружать все необходимые данные и копировать их в VO. Вы теряете прямое отображение между вашими постоянными объектами и вашим слоем представления (что означает, что вы должны написать больше кода), но вы можете обнаружить, что вы получаете ясность ...

Редактировать: Решение будет основано на компромиссах, поэтому я все еще думаю, что это по крайней мере частично вопрос личного вкуса. Транзакция на уровне сервиса кажется мне чище (более SOA-подобной, логика явно ограничена уровнем сервиса, разные вызовы четко разделены, ...). Проблема с этим подходом - LazyLoadingExceptions, которые могут быть решены с помощью VO. Если VO - это просто копия ваших постоянных объектов, то да, это явно нарушение принципа СУХОЙ. Если вы используете VO, как если бы вы использовали представление базы данных, VO - это упрощение ваших постоянных объектов. Это все еще будет больше кода для написания, но это сделает ваш дизайн более понятным. Это становится особенно полезным, если вам нужно подключить некоторую схему авторизации: если определенные поля видны только для определенных ролей, вы можете поставить авторизацию на уровне обслуживания и никогда не возвращать данные, которые не должны просматриваться.

Answer 2

Если я использую OSIV, я, по крайней мере, никогда столкнуться с отложенной загрузкой исключений

это не так, на самом деле его очень легко запустить в печально известную исключительную ситуацию LazyInitializationException, просто загрузить объект и попытаться прочитать его атрибут, после просмотра в зависимости от конфигурации вы получите LIE