Позвольте мне разобраться с этим. Во-первых, я написал несколько статей на эту тему в Использование ORM или простого SQL? . Специально для решения ваших пунктов:
Кривая обучения / простота использования
Ибатис о SQL. Если вы знаете SQL, кривая обучения для ibatis тривиальна. Ibatis делает некоторые вещи поверх SQL, такие как:
- сгруппировать по;
- различимые типы; и
- динамический SQL.
, что вам все еще нужно учиться, но самым большим препятствием является SQL.
JPA (который включает Hibernate), с другой стороны, пытается дистанцироваться от SQL и представлять вещи в объекте, а не в реляционной форме. Однако, как отмечает Джоэл, абстракции имеют утечку , и JPA не является исключением. Чтобы использовать JPA, вам все равно нужно знать о реляционных моделях, SQL, настройке производительности запросов и т. Д.
В то время как Ibatis просто попросит вас применить SQL, который вы знаете или изучаете, JPA потребует, чтобы вы знали кое-что еще: как его настроить (либо XML, либо аннотации). Под этим я подразумеваю выяснение того, что отношения внешнего ключа - это отношения (один-к-одному, один-ко-многим или многие-ко-многим), сопоставление типов и т. Д.
Если вы знаете SQL, я бы сказал, что барьер для изучения JPA на самом деле выше. Если вы этого не сделаете, это скорее смешанный результат с JPA, позволяющий вам на некоторое время эффективно отложить изучение SQL (но это не откладывает на неопределенное время).
С JPA, как только вы настроите свои сущности и их отношения, тогда другие разработчики могут просто использовать их, и им не нужно узнавать все о настройке JPA. Это может быть преимуществом, но разработчику все равно нужно знать о менеджерах сущностей, управлении транзакциями, управляемых и неуправляемых объектах и т. Д.
Стоит отметить, что JPA также имеет свой собственный язык запросов (JPA-SQL), который вам нужно будет узнать, знаете ли вы SQL. Вы найдете ситуации, когда JPA-SQL просто не может делать то, что может SQL.
Производительность
Об этом сложно судить. Лично я думаю, что я более продуктивен в ibatis, но я также очень доволен SQL. Некоторые утверждают, что они более продуктивны с Hibernate, но, возможно, это связано, по крайней мере частично, с незнанием SQL.
Также производительность с JPA обманчива, потому что вы иногда сталкиваетесь с проблемой с вашей моделью данных или запросами, которая занимает у вас от полдня до дня, чтобы решить, когда вы включаете ведение журнала и смотрите, какой SQL производит ваш JPA-провайдер. а затем вырабатываете комбинацию настроек и вызовов, чтобы получить что-то правильное и производительное.
У вас просто нет такой проблемы с Ibatis, потому что вы сами написали SQL. Вы можете проверить это, запустив SQL в PL / SQL Developer, SQL Server Management Studio, Navicat для MySQL или что-то еще. После того, как запрос верен, все, что вы делаете, это отображаете входы и выходы.
Также я обнаружил, что JPA-QL более неуклюжий, чем чистый SQL. Вам нужны отдельные инструменты, чтобы просто выполнить запрос JPA-QL, чтобы увидеть результаты, и это то, что вы должны изучить. Я действительно нашел всю эту часть JPA довольно неловкой и громоздкой, хотя некоторым это нравится.
ремонтопригодность / Стабильность
Опасность Ibatis в этом случае заключается в том, что ваша команда разработчиков может просто продолжать добавлять объекты-значения и запросы по мере необходимости, вместо того, чтобы искать повторное использование, в то время как JPA имеет одно право на таблицу, и как только вы получите эту сущность, вот и все. Именованные запросы имеют тенденцию идти к этой сущности, поэтому их трудно пропустить. Специальные запросы все еще могут повторяться, но я думаю, что это меньше потенциальной проблемы.
Однако это происходит за счет жесткости. Часто в приложении вам нужны кусочки данных из разных таблиц. С SQL это легко, потому что вы можете написать один запрос (или небольшое количество запросов), чтобы получить все эти данные одним ударом и поместить их в объект пользовательского значения только для этой цели.
С JPA вы продвигаете эту логику в свой бизнес-уровень. Сущности в основном все или ничего. Теперь это не совсем верно. Различные провайдеры JPA позволят вам частично загружать сущности и т. Д., Но даже там вы говорите об одних и тех же отдельных правах. Если вам нужны данные из 4 таблиц, вам нужно либо 4 объекта, либо вам нужно объединить нужные данные в какой-то объект настраиваемого значения на бизнес-уровне или уровне представления.
Еще одна вещь, которая мне нравится в ibatis, это то, что весь ваш SQL является внешним (в файлах XML). Некоторые будут ссылаться на это как недостаток, но не я. Затем вы можете относительно легко найти использование таблицы и / или столбца, выполнив поиск по вашим XML-файлам. С SQL, встроенным в код (или там, где вообще нет SQL), его может быть намного сложнее найти. Вы также можете вырезать и вставлять SQL в инструмент базы данных и запускать его. Я не могу переоценить, сколько раз это было полезно для меня за эти годы.
Производительность / масштабируемость
Здесь я думаю, что Ибатис побеждает. Это прямой SQL и низкая стоимость. По своей природе JPA просто не сможет управлять одинаковым уровнем задержки или пропускной способности. Теперь JPA стремится к тому, чтобы задержки и пропускная способность возникали редко. Высокопроизводительные системы, тем не менее, существуют и будут иметь тенденцию отказываться от более тяжелых решений, таких как JPA.
Плюс с ibatis вы можете написать запрос, который возвращает именно те данные, которые вы хотите, с точными столбцами, которые вам нужны. По сути, JPA не может превзойти (или даже сопоставить) это, когда возвращает дискретные объекты.
Простота устранения неисправностей
Я думаю, что это тоже победа для Ибатиса. Как я уже упоминал выше, в JPA вы иногда тратите полдня на то, чтобы получить запрос или сущность, чтобы получить нужный SQL-запрос, или диагностировать проблему в случае сбоя транзакции, поскольку менеджер сущностей попытался сохранить неуправляемый объект (который может быть частью пакета). работа, на которой вы проделали большую работу, так что найти ее может быть нетривиально).
Они оба потерпят неудачу, если вы попытаетесь использовать несуществующую таблицу или столбец, что хорошо.
Другие критерии
Теперь вы не упомянули переносимость как одно из ваших требований (имеется в виду перемещение между поставщиками баз данных). Стоит отметить, что здесь JPA имеет преимущество. Аннотации менее переносимы, чем, скажем, Hibernate XML (например, стандартные аннотации JPA не имеют эквивалента для «родного» идентификатора Hibernate), но обе они более переносимы, чем ibatis / SQL.
Также я видел JPA / Hibernate, используемый в качестве формы переносимого DDL, что означает, что вы запускаете небольшую Java-программу, которая создает схему базы данных из конфигурации JPA. С ibatis вам потребуется скрипт для каждой поддерживаемой базы данных.
Недостатком переносимости является то, что JPA является, в некотором смысле, наименьшим общим знаменателем, что означает, что поддерживаемое поведение является в основном распространенным поддерживаемым поведением для широкого круга поставщиков баз данных. Если вы хотите использовать Oracle Analytics в ibatis, нет проблем. В JPA? Ну, это проблема.