JPA по сравнению с JDBC, хранимыми процедурами и Co. или Как убедить старого школьного программиста пробовать ORM?
Это - что-то, что я периодически имею дело с, и в первый раз, когда это был я, кому было нужно убеждение. К счастью я просто попробовал, приложил дополнительное усилие для изучения и благодаря этой книге, Пружинной опоре, и Быть в спящем режиме я не запущу проект, не рассматривая JPA. Но не все готовы пойти дополнительная миля, с которой часто (только в чем-либо мы имеем дело, я предполагаю). Таким образом, как и что говорить/представлять/объяснять/аргумент, чтобы, по крайней мере, сместить их отношение к ORM?
Похожие страницы: Убеждение умирания твердого DBA для использования ORM для большинства CRUD по сравнению с Хранимыми процедурами, Представлением и Функциями
5 ответов
Я предположу, что у вас действительно есть объектная модель, более богатая, чем просто DTO, а не просто соответствие 1:1 с вашей реляционной схемой. Если нет, то вы не выиграете спор.
Вы выиграете, если SQL, генерируемый Hibernate, будет по крайней мере столь же эффективен, как и написанный вручную материал в хранимых процедурах.
Вы проиграете, если хранимые процедуры можно оптимизировать так, чтобы они работали лучше, чем SQL, сгенерированный Hibernate.
Вы проиграете, если база данных будет совместно использоваться другими приложениями, которые зависят от хранимых процедур. Вы не сможете так же легко перенести логику в Spring и на средний уровень.
У вас больше шансов, если ваше приложение владеет базой данных.
Поскольку вы уже используете Spring, это предполагает, что у вас есть уровень DAO, который использует преимущества Spring Validation. Под ним уже используются PreparedStatements, поэтому SQL-инъекции для Spring так же маловероятны, как и для хранимых процедур.
Хорошо, я собираюсь сыграть здесь адвоката дьявола.
Хранимые процедуры - это уровень абстракции. JPA требует, чтобы вы знали базовую структуру таблицы. Хранимые процедуры / функции маскируют это; вам нужно только знать вызываемую процедуру или функцию и тип ее возвращаемого значения.
JDBC упрощает вызов хранимых процедур с помощью методов prepareCall объекта Connection.
Хранимые процедуры также добавляют уровень безопасности: само приложение обычно не может вручную изменять таблицы, а только вызывает процедуры, которые вносят изменения. SP / SF также должен проверять переданные ему аргументы.
Основным недостатком хранимых процедур является получение данных обратно ... вам нужно создать собственное средство для сопоставления массивов и структур, возвращающихся к объектам Java, обычно с картой типа и специально созданной программно. объекты, реализующие интерфейс SQLData .
Так как и что сказать/представить/объяснить/аргументировать, чтобы хотя бы сдвинуть их отношение к ORM?
Спросите, хотят ли они продолжать писать один и тот же шаблонный код SQL JDBC CRUD для каждого нового типа сущностей, который вы добавляете в свое приложение.
Без ORM-решения на уровне данных каждый новый класс сущностей требует N единиц работы, чтобы сделать эту сущность доступной на уровне данных (DAO, CRUD-код, хранимые процедуры, написание запросов и т.д.).
ORM превращает это N в часть себя, предполагая, что добавление новых сущностей требует просто добавить еще одно отображение для этой сущности в метаданных.
Меньше шаблонов и дополнительная безопасность. Вы можете сохранить пальцы, а младшие программисты имеют меньше шансов внедрить уязвимости SQL-инъекций, которые я считаю очень важными.
Я думаю этот ответ из вашей ссылки на соответствующий вопрос решает основную проблему.Если цель базы данных тесно связана с вашим приложением и на самом деле у нее нет отдельного идентификатора, тогда ORM имеет смысл.
Если, однако, ваша база данных представляет собой более широкую картину, а ваше приложение является одним из многих приложений, которые получают доступ к данным, использование ORM может иметь потенциально негативное влияние на связь между вашим приложением и базой данных и необходимость изменения базы данных. время.
Но в какой-то степени вы можете сами ответить на свой вопрос - какие у вас были возражения? Как вас убедили в первый раз?