JPA против JDBC, хранимые процедуры и Co. Как убедить программиста старой школы попробовать ORM?

Question

Это то, с чем я периодически сталкиваюсь, и впервые я нуждалась в убеждении. К счастью, я только что попробовал, приложил дополнительные усилия для изучения, и благодаря этой книге , поддержке Spring и Hibernate я не начну проект без рассмотрения JPA. Но не все готовы идти на милю так часто (наверное, во всем, с чем мы имеем дело). Так как и что сказать / представить / объяснить / аргументировать, чтобы хотя бы изменить свое отношение к ORM?

Связанный: Убедительный жесткий DBA для использования ORM для большинства CRUD против хранимых процедур, просмотра и функций

Answer 1

Я предполагаю, что у вас действительно есть объектная модель, которая богаче простых DTO, а не просто соответствие 1: 1 вашей реляционной схеме. Если нет, вы не выиграете спор.

Вы выиграете, если SQL, сгенерированный Hibernate, по крайней мере так же эффективен, как и код, написанный вручную, который хранится в хранимых процессах.

Вы проиграете, если хранимые процессы будут оптимизированы для лучшей производительности, чем сгенерированный Hiberate SQL.

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

У вас есть лучший случай, если ваше приложение владеет базой данных.

Поскольку вы уже используете Spring, это говорит о том, что у вас есть слой DAO, использующий преимущества Spring Validation. PreparedStatements уже используются под ним, поэтому внедрение SQL столь же маловероятно для Spring, как и для хранимых процедур.

Answer 2

ОК, я собираюсь сыграть здесь адвоката дьявола.

Хранимые процедуры - это слой абстракции.JPA требует, чтобы вы знали основную структуру таблицы.Хранимые процедуры / функции маскируют это;вам нужно знать только процедуру или функцию для вызова и тип ее возврата.

JDBC упрощает вызов хранимых процедур, используя методы prepareCall объекта Connection.

Хранимые процедуры также добавляют уровень безопасности: само приложение обычно не может изменять таблицы вручную, а только вызывает процедуры, которые вносят изменения.SP / SF также должен проверять переданные ему аргументы.

Главный недостаток хранимых процедур - возврат данных ... вам нужно создать собственное средство для сопоставления массивов и структур, возвращающихся в Java.объекты, как правило, с картой типа и специальные программно созданные объекты, реализующие интерфейс SQLData.

Answer 3

Так как и что сказать / представить / объяснить / аргументировать, чтобы хотя бы изменить свое отношение к ОРМ?

Спросите, хотят ли они продолжать писать один и тот же стандартный код JDBC CRUD для каждого нового типа сущности, добавляемого в ваше приложение.

Без решения ORM на уровне данных каждому новому классу объектов требуется N единиц работы, чтобы сделать этот объект доступным через уровень данных (DAO, код CRUD, хранимые процедуры, написание запросов и т. Д.).

ORM преобразует этот N в часть себя, предполагая, что для добавления новых сущностей необходимо просто добавить еще одно сопоставление для этой сущности в метаданных.

Answer 4

Ответ на ваш вопрос на самом деле довольно прост и совершенно не зависит от того, твердолобый ли вы администратор баз данных. Вы должны спросить себя:

Вы пишете приложение, ориентированное на модель домена, с большим количеством CRUD?

Или вы пишете приложение, ориентированное на реляционные модели, с небольшим количеством CRUD?

В первом случае выберите ORM. Во втором случае выберите SQL. Если у вас есть оба в вашем приложении, выберите оба. Эти две модели не являются взаимоисключающими, хотя ORM do накладывают множество правил на дизайн вашего приложения.

Обратите внимание, что ORM не являются "следующей вещью" в мире Java. Это отличное изобретение для решения только некоторых проблем (а именно сложных или повторяющихся CRUD)

Answer 5

Я думаю этот ответ из вашей связанной ссылки на вопрос пригвоздит основную проблему. Если цель базы данных тесно связана с вашим приложением и у нее нет отдельного идентификатора, тогда ORM имеет смысл.

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

Но в какой-то степени вы сами можете ответить на свой вопрос - какие у вас были возражения? Как вы были убеждены в первый раз?

Answer 6

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

Answer 7

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

Если в приложении есть ошибка, вы должны подумать: это код или что-то в этой хранимой процедуре.

Кроме того, как вы тестируете SP изолированно?

Помните, ошибка в коде и ошибка в базе данных могут хорошо удвоиться, чтобы создать работающее решение. Так же, как в математике два негатива делают позитив. Это становится хаосом, когда SP исправлен без исправления кода, и наоборот.