JPA / ORM против JDBC для машин с ограниченной производительностью

Question

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

Я хотел бы использовать JPA, поскольку он упрощает код и устраняет необходимость в коде ResultSet JDBC. Тем не менее, будут ли накладные расходы JPA на таких небольших машинах фактором? Я думаю об использовании Toplink в настоящее время, который поставляется в 2,5-мегабайтном файле JAR.

У нас ограниченное количество таблиц, поэтому код JDBC не доставит особых хлопот. Но JPA делает код таким красивым.

Приветствие.

Answer 1

Производительность JPA / ORM во время выполнения всегда будет больше или равна JDBC, так как они оба основаны на JDBC.

Как вы заметили, большой подъем, который вы получаете от JPA / ORM, находится во время разработки.

Я хотел бы использовать JPA, так как он упрощает код и устраняет необходимость в коде ResultSet JDBC.

Я не уверен, что понимаю это утверждение. JPA будет использовать ResultSet за кулисами; ты просто не будешь это писать. Отображение из ResultSet в объекты инкапсулируется в XML или аннотации.

Если вы действительно ограничены памятью, вам, возможно, придется передать JPA и вручную кодировать JDBC.

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

256 МБ ОЗУ? Вам будет трудно использовать любые сторонние библиотеки.

Answer 2

В зависимости от операционной системы и того, что еще у вас работает, 256 МБ ОЗУ не так мало, как вы думаете. Может быть вполне возможно использовать решение ORM, но лучший способ - это проверить и убедиться в этом самому.

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

Вы также можете ограничить память JVM до определенного уровня, что приведет к большему количеству сборщиков мусора, но должно предотвратить сбой, если вы не достигнете предела.