Где "@Transactional " должен быть слой сервиса или DAO
во-первых, возможно, что я спрашиваю что-то, что было задано и ответили раньше, но я не мог получить результат поиска обратно . Хорошо вообще (или всегда до сих пор:)) мы определяем транзакционные аннотации на уровне сервиса типичный spring hibernate crud обычно
Контроллер- > Менеджер - >Dao - >Orm .
теперь у меня есть ситуация, когда мне нужно выбрать между моделью домена на основе сайта клиента . Скажем, клиент A использует мою модель домена хорошо, но тогда другой клиентский сайт даст мне веб-сервис и не будет использовать нашу модель домена .
какой слой я должен заменить . Я считаю, что это должен быть Dao, который будет получать мне данные из веб-службы и отправлять их обратно.Я. e два отдельно написанных слоя Dao и подключены на основе сценария .
теперь я понял, что мы делаем плотную связь (если есть такая вещь или сказать, не имея свободной связи) , когда мы помещаем @Transactional в слой обслуживания . Так много мозгов не может ошибаться или они (я сомневаюсь).
Итак, вопрос: "где" @Transactional " должен быть слой сервиса или DAO ?"и это сервисный уровень вниз, который я должен заменить .
5 ответов
В идеале Service layer (Manager) представляет вашу бизнес-логику и, следовательно, она должна быть аннотирована с помощью @Transactional.
уровень обслуживания может вызывать различные DAO для выполнения операций БД. Предположим, что в методе службы имеется 3 операции DAO. Если ваша 1-я операция DAO не удалась, другие два могут быть все еще переданы, и вы закончите непоследовательным состоянием БД. Аннотирование уровня сервиса может избавить вас от таких ситуаций.
вы хотите, чтобы ваши услуги были транзакционными. Если ваши DAOs являются транзакционными, и вы вызываете разные DAOs в каждой службе, тогда у вас будет несколько txs, что не то, что вы хотите. Сделайте вызовы службы транзакционными, и все вызовы DAO внутри этих методов будут участвовать в tx для метода.
Я предложу поместить @Transactional в методы уровня обслуживания, так как мы можем иметь несколько реализаций DAO. используя это, мы можем сделать наши услуги транзакционными. refer
рекомендуется использовать общий BasicService для предоставления общих служб.
сервис является лучшим местом для размещения @Transactional, уровень сервиса должен содержать поведение прецедента уровня детализации для взаимодействия с пользователем, которое логически войдет в транзакцию. таким образом мы можем поддерживать разделение кода веб-приложения и бизнес-логику.
есть много приложений CRUD, которые не имеют какой-либо значительной бизнес-логики, для них наличие сервисного уровня, который просто передает материал между контроллерами и объектами доступа к данным, не полезно. В этих случаях мы можем поместить аннотацию транзакции в Dao.
Так что на практике вы можете поместить их в любом месте это до вас.
, имея несколько вызовы в вашем сервисе вам нужно @Transactional в сервисе. различные вызовы службы будут выполняться в разных транзакциях, если вы поставите @Transactional в службу.
Это личный выбор, основанный на типах приложений, если приложение является layerd во многих модулях ,и большинство операций основаны на @CRUD, то наличие аннотации @transactional на уровне обслуживания делает больше смысла.. приложение типа двигателя, такое как планировщики , серверы заданий, приложения отчетов@etl, где сеансы и концепция пользователя не существуют, тогда наиболее подходящей является транзакция распространения на уровне контекста... мы не должны создавать транзакции clusterd, помещая @transactional каждый, где в конечном итоге транзакционные анти-паттеры...в любом случае для прагматического управления транзакциями JTA2 является наиболее подходящим ответом...опять же, это зависит от погоды, которую вы можете использовать в определенных ситуациях...
вы должны использовать @Transactional на уровне службы, если вы хотите изменить модель домена для клиента B, где вы должны предоставить те же данные в другой модели,вы можете изменить модель домена без влияния на уровень DAO, предоставив другую службу или создав интерфейс и реализовав интерфейс в другой модели и с той же службой заполнить модель на основе клиента.Это решение основано на бизнес-требовании и объеме проект.