JPA против Spring JdbcTemplate

Question

Для нового проекта JPA всегда является рекомендуемым инструментом для обработки реляционных данных или существуют сценарии, в которых Spring JdbcTemplate является лучшим выбором?Некоторые факторы, которые следует учитывать в вашем ответе:

• новая схема базы данных по сравнению с ранее существовавшей схемой и таблицами
• уровень знаний разработчика
• легкость, с которой можно интегрироваться суровень кэширования данных
• производительность
• любые другие важные факторы, которые следует учитывать?

Answer 1

Используйте Spring JdbcTemplate, если вы не хотите получать доступ к вашей схеме базы данных через модель домена.Используя JdbcTemplate, вы используете доступ более низкого уровня, с большей гибкостью, но, вероятно, также с большим количеством шаблонов.

Spring JdbcTemplate легче использовать с экзотическими схемами базы данных и фокусом хранимых процедур.Используя JPA, вы должны убедиться, что схема базы данных правильно отображается в модели предметной области.

Обе технологии нуждаются в разработчиках, знающих реляционные базы данных, SQL и транзакции.Однако с JPA вы получаете более скрытую сложность.

Насколько мне известно, JPA легче подключается к слоям кэширования данных, поскольку объектно-ориентированный фокус упрощает идентификацию, обновление и аннулирование записей в кэше.может лучше настроить бэкенды на основе JdbcTemplate, но в большинстве случаев требуется больше кода.

Еще один аспект, который следует учитывать, заключается в том, что, хотя с JPA вы получаете модель домена для схемы базы данных, вам часто придется использовать дополнительныеDTO классы.Используя JdbcTemplate, вы можете напрямую работать с классами DTO.

Answer 2

Я немного опоздал на этот пост, но я склонен использовать JdbcTemplate поверх ORM.Я знаю SQL (довольно хорошо) и действительно не хочу, чтобы меня "абстрагировали" от моей БД.Я нахожу большую часть времени, мои приложения используют представления БД, где я использую большую часть бизнес-логики.Я правильно настроил DAO с реализациями JdbcTemplate.Он кажется «чистым», и большинство шаблонного кода скрыто JdbcTemplate (и его онлайн-документация кажется НАМНОГО лучше, чем ORM).Ограниченное время, в течение которого я использовал что-то вроде Hibernate, я обнаружил, когда оно работало, это экономило мне время ... но когда оно не работало должным образом, это стоило мне дней отладки "WTF".Мне никогда не приходилось тратить более 20 минут на отладку JdbcTemplate DAO.Я думаю, что ключ, как отмечали другие, в том, насколько вам комфортно с SQL / Schema Design

Answer 3

Я согласен с @Timo.Единственное другое понимание, которое я бы добавил / расширил, заключается в том, что ORM имеет семантику, отличную от доступа к вашим данным с использованием чистого SQL.

Смысл ORM состоит в том, чтобы абстрагироваться от того факта, что ваши данные вообще находятся в БД,как можно больше.При правильном использовании ORM все персистентные операции выполняются в один (надеюсь) тонкий слой.Ваши объекты модели будут иметь мало или вообще не иметь постоянного кода;тот факт, что вы используете ORM, должен быть невидим для вашей модели.

Благодаря этому ORM очень хорошо облегчает вашу жизнь для определенных типов операций, а именно простых операций CRUD.Вы можете загрузить объекты вашей модели, представить их, обновить их, удалить их довольно легко.Это облегчает вашу жизнь, потому что когда вы получаете доступ к своим данным, вы возвращаете объекты модели, на которых вы можете написать бизнес-логику.Если вы используете JDBC, вам придется «гидрировать» экземпляры вашего объекта из данных, что может быть сложным и подверженным ошибкам.

ORM не всегда лучший выбор.JPA - это инструмент для работы, если инструмента недостаточно для работы, вы захотите найти лучший инструмент.Например, у меня был сценарий, когда мне приходилось копировать весь граф объектов и сохранять новую копию этих объектов.Если бы я использовал ORM (как я пытался это сделать), мне пришлось бы загрузить все объекты из БД, затем скопировать их, а затем сохранить новые объекты.Я занимал слишком много времени.

Лучшим решением было просто использовать операции на основе jdbc и вызовы sql «вставка через select» для создания новых строк.Это было быстро, код был проще.

Еще одна вещь, которую следует учитывать, это то, что вы чувствуете себя комфортно с JDBC, и у вас есть крайние сроки, вам не нужно прыгать на подножку ORM.Классы Spring JdbcTemplate являются чрезвычайно мощными и полезными.Иногда лучшим инструментом для работы является тот, который вы знаете.Вы должны ознакомиться с ORM, но не обязательно для проекта с высокими ожиданиями.Есть чему поучиться, и это не тривиально - на самом деле вы торгуете одним набором сложностей с другим при выборе использования jdbc vs orm.

Answer 4

Это не упоминается в других ответах, но можно использовать оба. В моем приложении я использую 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, когда это имеет смысл.

Answer 5

На работе мы используем Hibernate JDBCTemplate, потому что он обладает большей гибкостью. Он также имеет лучшую производительность, чем JPA, потому что вы не «загружаете» много ненужных данных в свое приложение.
В случае JDBCTemplate ваши навыки SQL имеют большое значение, давая вам именно то, что вам нужно с правильной скоростью.