Один переезд равен двум пожарам: из JPA в JDBC и обратно
Очень часто мы слышим фразу "У нас приложение тормозит из-за JPA (или JDBC)! Давайте переедем на JDBC (JPA) и все взлетит!". Казалось бы, это не очень сложно: давайте заменим слой доступа к данным, и на этом все закончится. Особенно легко это выглядит в случае использования Spring: давайте заменим все Spring Data JPA репозитории на Spring Data JDBC (или наоборот) - и всё!
Но нужно отметить, что между JPA и JDBC есть разница в подходе к проектированию приложения. В JPA мы работаем с объектами, а БД – всего лишь персистентное хранилище для них. В JDBC мы работаем с базой данных, а результатом этой работы являются объекты, используемые в приложении. И вот эта разница может внести дополнительные сложности при переходе с одной технологии на другую.
В докладе мы обсудим тонкие моменты, с которыми вы можете столкнуться при таком переходе.
• Как поменяется модель данных
• Нужно ли переделывать репозитории
• Решится ли проблема N+1 запроса
• Как жить без L1 кэша
• Признаки того, что нужно переходить с JPA на JDBC или с JDBC на JPA.
Все эти вопросы мы проиллюстрируем примерами кода.
Очень часто мы слышим фразу "У нас приложение тормозит из-за JPA (или JDBC)! Давайте переедем на JDBC (JPA) и все взлетит!". Казалось бы, это не очень сложно: давайте заменим слой доступа к данным, и на этом все закончится. Особенно легко это выглядит в случае использования Spring: давайте заменим все Spring Data JPA репозитории на Spring Data JDBC (или наоборот) - и всё!
Но нужно отметить, что между JPA и JDBC есть разница в подходе к проектированию приложения. В JPA мы работаем с объектами, а БД – всего лишь персистентное хранилище для них. В JDBC мы работаем с базой данных, а результатом этой работы являются объекты, используемые в приложении. И вот эта разница может внести дополнительные сложности при переходе с одной технологии на другую.
В докладе мы обсудим тонкие моменты, с которыми вы можете столкнуться при таком переходе.
• Как поменяется модель данных
• Нужно ли переделывать репозитории
• Решится ли проблема N+1 запроса
• Как жить без L1 кэша
• Признаки того, что нужно переходить с JPA на JDBC или с JDBC на JPA.
Все эти вопросы мы проиллюстрируем примерами кода.
Один переезд равен двум пожарам: из JPA в JDBC и обратно
Очень часто мы слышим фразу "У нас приложение тормозит из-за JPA (или JDBC)! Давайте переедем на JDBC (JPA) и все взлетит!". Казалось бы, это не очень сложно: давайте заменим слой доступа к данным, и на этом все закончится. Особенно легко это выглядит в случае использования Spring: давайте заменим все Spring Data JPA репозитории на Spring Data JDBC (или наоборот) - и всё!
Но нужно отметить, что между JPA и JDBC есть разница в подходе к проектированию приложения. В JPA мы работаем с объектами, а БД – всего лишь персистентное хранилище для них. В JDBC мы работаем с базой данных, а результатом этой работы являются объекты, используемые в приложении. И вот эта разница может внести дополнительные сложности при переходе с одной технологии на другую.
В докладе мы обсудим тонкие моменты, с которыми вы можете столкнуться при таком переходе.
• Как поменяется модель данных
• Нужно ли переделывать репозитории
• Решится ли проблема N+1 запроса
• Как жить без L1 кэша
• Признаки того, что нужно переходить с JPA на JDBC или с JDBC на JPA.
Все эти вопросы мы проиллюстрируем примерами кода.
Но нужно отметить, что между JPA и JDBC есть разница в подходе к проектированию приложения. В JPA мы работаем с объектами, а БД – всего лишь персистентное хранилище для них. В JDBC мы работаем с базой данных, а результатом этой работы являются объекты, используемые в приложении. И вот эта разница может внести дополнительные сложности при переходе с одной технологии на другую.
В докладе мы обсудим тонкие моменты, с которыми вы можете столкнуться при таком переходе.
• Как поменяется модель данных
• Нужно ли переделывать репозитории
• Решится ли проблема N+1 запроса
• Как жить без L1 кэша
• Признаки того, что нужно переходить с JPA на JDBC или с JDBC на JPA.
Все эти вопросы мы проиллюстрируем примерами кода.
О докладчике
О докладчике
Developer Advocate в компании Haulmont. С Java начал плотно работать с 2006 года. Долго работал в аутсорсинге, где попробовал себя почти во всех ролях, кроме, пожалуй, дизайнера. Был разработчиком, техлидом, ПМом, архитектором. В настоящее время работаю над фреймворком Jmix в компании Haulmont — делаю RnD и представляю компанию на разных мероприятиях.
Все спикеры SnowOne
Все спикеры SnowOne