Где должен быть "@Transactional" - уровень обслуживания или DAO

Question

Во-первых, возможно, что я спрашиваю что-то, о чем уже спрашивали и отвечали раньше, но мне не удалось получить результат поиска.Ладно, в общем (или всегда так далеко :)) Мы определяем транзакционные аннотации на сервисном уровне. Типичный весенний спящий режим обычно

Контроллер-> Менеджер-> Дао-> Орм.

У меня сейчас есть ситуация, когда мне нужно выбирать между моделью домена, основанной на сайте клиента.Скажем, клиент А использует мою модель домена, все хорошо, но тогда другой клиентский сайт предоставит мне веб-сервис, а не будет использовать нашу модель домена.

Какой слой я должен заменить.Я полагаю, что это должен быть Dao, который будет получать мне данные из веб-службы и отправлять их обратно. То есть два отдельно написанных слоя Dao и подключаться в зависимости от сценария.

Теперь я понял, что мы напряженно работаемсвязывание (если есть такая вещь или, скажем, отсутствие слабой связи), когда мы помещаем @Transactional в слой Service.Так много мозгов не могут ошибаться или они (я в этом сомневаюсь).

Итак, вопрос в том, "где должно быть" @Transactional ", чтобы разместить Service Layer или DAO?"и это сервисный слой вниз, я должен заменить.

Answer 1

В идеале, Сервисный уровень (Менеджер) представляет вашу бизнес-логику, и поэтому он должен быть аннотирован @ Transactional.

Сервисный уровень может вызывать разные DAO для выполнения операций с БД. Предположим, что у вас есть 3 операции DAO в сервисном методе. Если ваша 1-я операция DAO завершилась неудачно, другие две могут все еще быть пропущены, и вы получите несовместимое состояние БД. Слой Annoating Service может спасти вас от таких ситуаций.

Answer 2

Вы хотите, чтобы ваши услуги были транзакционными. Если ваши DAO являются транзакционными, и вы вызываете разные DAO в каждой службе, то у вас будет несколько txs, а это не то, что вам нужно. Сделайте вызовы служб транзакционными, и все вызовы DAO внутри этих методов будут участвовать в передаче метода.

Answer 3

Я предлагаю поместить @Transactional в методы уровня сервиса, поскольку у нас может быть несколько реализаций DAO.с помощью этого мы можем сделать наши услуги транзакционными. см.

. Лучше всего использовать универсальный базовый сервис для предоставления общих услуг.

Сервис - лучшее место для размещения @Transactional, уровень сервиса должен содержать детализацию.Поведение на уровне использования для взаимодействия с пользователем, которое логически должно происходить в транзакции.таким образом мы можем поддерживать разделение между кодом веб-приложения и бизнес-логикой.

Есть много приложений CRUD, которые не имеют какой-либо существенной бизнес-логики, поскольку у них есть сервисный уровень, который просто пропускает вещи черезмежду контроллерами и объектами доступа к данным не полезно.В этих случаях мы можем поместить аннотацию транзакции в Dao.

Таким образом, на практике вы можете разместить их в любом месте, это ваше дело.

При наличии нескольких вызовов в вашем сервисе вам понадобится @Transactionalв сервисе.разные вызовы в службу будут выполняться в разных транзакциях, если вы введете @Transactional в службу.

Answer 4

Вы должны использовать @Transactional на уровне сервиса, если вы хотите изменить модель домена для клиента B, где вы должны предоставить те же данные в другой модели, вы можете изменить модель домена, не влияя на уровень DAO, предоставивдругой сервис или путем создания интерфейса и реализации интерфейса в другой модели и с одним и тем же сервисом, заполняют модель на основе клиента. Это решение основывается на требованиях бизнеса и масштабах проекта.

Answer 5

Это персональный выбор, основанный на типах приложений, если приложение распределено по многим модулям и большинство операций основано на @CRUD, тогда наличие аннотации @transactional на уровне обслуживания делает больше смысла .. приложение типа двигателя, такое как планировщики, серверы заданий , @ etl отчеты о приложениях, где сеансы и пользовательская концепция не существуют, тогда распространяющиеся транзакции на уровне контекста являются наиболее подходящими ... мы не должны в конечном итоге создавать кластеризованные транзакции, помещая @transactional везде, где заканчиваются транзакционные анти-паттерны ... в любом случае для прагматичного управления транзакциями JTA2 является наиболее подходящим ответом ... опять же, это зависит от погоды, которую вы можете использовать в определенных ситуациях ...