Для нового проекта JPA всегда является рекомендуемым инструментом для обработки реляционных данных или существуют ли сценарии, где Spring JdbcTemplate - лучший выбор? Некоторые факторы, которые следует учитывать в вашем ответе:
Используйте Spring JdbcTemplate, если вы не хотите получать доступ к вашей схеме базы данных с помощью модели домена. Используя JdbcTemplate, вы используете доступ на более низком уровне, с большей гибкостью, но, вероятно, также с большим количеством шаблонов.
Spring JdbcTemplate можно более легко использовать с экзотическими схемами баз данных и фокусом хранимой процедуры. Используя JPA, вы должны убедиться, что схема базы данных правильно отображена в модели домена.
Обеим технологиям нужны разработчики, которые знают реляционные базы данных, SQL и транзакции. Вместе с JPA вы получаете более скрытую сложность.
JPA, насколько мне известно, легче подключается к уровням кэширования данных, поскольку объектно-ориентированный фокус упрощает идентификацию, обновление и отмену ввода-вывода кэша.
Вы можете лучше настроить основы на основе JdbcTemplate, но в большинстве случаев используется больше кода.
Некоторые другие аспекты, которые следует учитывать, это то, что, хотя с JPA вы получаете модель домена для своей схемы базы данных, вам часто придется использовать дополнительные классы DTO. Используя JdbcTemplate, вы можете напрямую работать с классами DTO.
Я немного опаздываю на этот пост, но я склонен использовать JdbcTemplate для ORM. Я знаю SQL (довольно хорошо) и на самом деле не хочу "отвлекаться" от моей БД. Я нахожу большую часть времени, мои приложения используют представления БД, где я выдвигаю большинство бизнес-логики. У меня есть правильно слоистые DAO, у которых есть реализации JdbcTemplate. Он чувствует себя "чистым", и самый шаблонный код скрыт JdbcTemplate (и его онлайн-документация кажется МНОГО лучше, чем материал ORM). В ограниченное время, когда я использовал что-то вроде Hibernate, я обнаружил, что когда это сработало, это избавляет меня от времени... но когда он не работал должным образом, это стоило мне дней отладки WTF. Мне никогда не приходилось тратить более 20 минут на отладку JdbcTemplate DAO impls. Я думаю, что ключевым, как отмечали другие, является то, насколько вы комфортно работаете с SQL/Schema Design
Я согласен с @Timo. Единственное другое понимание, которое я хотел бы добавить/расширить, заключается в том, что ORM имеет разную семантику от чистого доступа к вашим данным на базе sql.
Точка ORM должна абстрагироваться от факта, что ваши данные находятся в БД вообще, насколько это возможно. Когда вы используете ORM правильно, все операции сохранения выполняются одним (надеюсь) тонким слоем. Объекты вашей модели не будут иметь почти никакого кода сохранения; тот факт, что вы используете ORM, должен быть невидимым для вашей модели.
Из-за этого ORM очень хорош в том, чтобы сделать вашу жизнь легкой для определенных типов операций, а именно простых операций CRUD. Вы можете загружать объекты модели, представлять их, обновлять их, легко удалять. Это облегчает вашу жизнь, потому что, когда вы получаете доступ к своим данным, вы возвращаете объекты модели, на которых вы можете писать бизнес-логику. Если вы используете JDBC, вам придется "убрать" ваши экземпляры объектов из данных, что может быть сложным и подверженным ошибкам.
ORM не всегда лучший выбор. JPA - это инструмент для работы, если инструмент недостаточно для задания, вам нужно найти лучший инструмент. Например, у меня был сценарий, когда мне пришлось скопировать весь граф объектов и сохранить новую копию этих объектов. Если я использовал ORM (как я и пытался это сделать), мне пришлось загрузить все объекты из БД, затем скопировать их, а затем сохранить новые объекты. Я слишком долго занимался.
Лучшим решением было просто использовать операции на основе jdbc и "вставить через select" sql-вызовы для создания новых строк. Это было быстро, код был проще.
Другая вещь, которую следует учитывать, - это то, что вам комфортно с JDBC, и у вас есть крайние сроки, вам не нужно прыгать на победителя ORM. Классы Spring JdbcTemplate чрезвычайно эффективны и полезны. Иногда лучшим инструментом для работы является тот, который вы знаете. Вы должны ознакомиться с ORM, но не обязательно для проекта с высокими ожиданиями. Существует много возможностей для изучения, и его нетривиально - действительно, вы торгуете одним набором сложностей с другим в выборе использования jdbc vs orm.
Это не упоминается в других ответах, но хорошо использовать оба. В моем приложении я использую JPA и JdbcTemplate, для операций типа crud я использую JPA, но для отчетов или там, где это проще, я использую jdbcTemplate.
@Repository
public class FooRepository
{
@PersistenceContext
private EntityManager entityManager;
@Autowired(required = true)
private JdbcTemplate jdbcTemplate;
public void saveFoo(Foo foo)
{
this.entityManager.persist(foo);
}
public List<SomeReportPojo> getSomeReport()
{
return this.entityManager.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
Самое замечательное в Spring заключается в том, что перевод исключений из исключений JPA в Spring иерархию исключений Dao работает как с JPA, так и с jdbcTemplate. Поэтому используйте JPA, когда это имеет смысл, и jdbcTemplate, когда это имеет смысл.
На работе мы используем Hibernate JDBCTemplate, потому что он обладает большей гибкостью. Он также имеет лучшую производительность, чем JPA, потому что вы не загружаете много ненужных данных в свое приложение.
В случае JDBCTemplate ваши навыки SQL дают долгий путь, давая вам именно то, что вам нужно с правильной скоростью.