Где должно быть «@Transactional» размещать Service Layer или DAO

Question

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

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

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

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

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

Таким образом, вопрос: «Где должно быть @Transactional» размещать Service Layer или DAO? » и это слой обслуживания вниз, я должен заменить.

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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