Решения ORM (JPA; Будьте в спящем режиме) по сравнению с JDBC
Я нашел это простым понятным и легко объяснимым решением
public class GenericClass<T> {
private Class classForT(T...t) {
return t.getClass().getComponentType();
}
public static void main(String[] args) {
GenericClass<String> g = new GenericClass<String>();
System.out.println(g.classForT());
System.out.println(String.class);
}
}
5 ответов
У нас есть подобный опыт при сравнении, в спящем режиме с JDBC в пакетном режиме (Statement#executeBatch ()). В основном это походит, в спящем режиме, просто не делает этого хорошо с объемными операциями. В нашем случае Быть в спящем режиме реализация была достаточно быстра на наших производственных аппаратных средствах.
то, Что можно хотеть сделать, должно перенести вызовы базы данных в ДАО, дав приложению последовательный способ получить доступ данным. Реализуйте свои ДАО с, в спящем режиме, где удобно, и с JDBC, где требования к производительности призывают к нему.
Будьте в спящем режиме поддерживает кэш первого уровня объектов использовать в грязной проверке, а также действовать как Карта Единицы работы и Идентификационных данных. Это добавляет к издержкам, особенно в операциях объемного типа. Для объемных операций можно хотеть заняться расследованиями StatelessSessions, которые не поддерживают это состояние.
Как минимум, необходимо сделать, пакет вставляет в, Будьте в спящем режиме: http://www.hibernate.org/hib_docs/reference/en/html/batch.html Сохраняет много круговой задержки.
И, как Судья упомянул, основной целью Hib не является производительность компьютера, но производительность разработчика. Однако обычно возможно достигнуть сопоставимый (не равный, но не, что намного хуже) к JDBC заканчивается.
Все это отображение..., это может стать немного дорогим со всей тайной логикой и всем отражением и проверкой непротиворечивости, которую это должно сделать.
точка отображения не должна повышать производительность, конечно. Как правило, Вы получаете удар производительности. Но что Вы теряете в производительности, Вы ( может ), усиление много раз в производительности разработчика, непротиворечивости, тестируемости, надежности и еще таком количестве желанных атрибутов. Как правило, когда Вам нужна дополнительная производительность, и Вы не хотите бросать отображаться, Вы заглядываете еще некоторым аппаратным средствам.
Никогда не используйте одну технологию для всех проблем. В зависимости от проблемы решайте, какую технологию использовать. Конечно, jpa или hibernate медленнее, чем jdbc. jdbc находится на более низком уровне, чем jpa. Также профессионал по базам данных с jdbc может написать более оптимизированный sql, чем jpa. Если вы указали критическую точку, где требуется скорость, jpa не ваш выбор.