У меня есть толстый клиент, приложение java swing со схемой из 25 таблиц и ~ 15 JInternalFrames (формы ввода данных для таблиц). Мне нужно сделать выбор дизайна прямого JDBC или ORM (спящий режим с фреймворком spring в этом случае) для взаимодействия СУБД. Построение вне приложения будет происходить в будущем.
Будет ли спящий режим перегружать проект такого размера? Объяснение ответа "да" или "нет" было бы высоко оценено (или даже другим подходом, если это оправдано).
ТИА.
Хороший вопрос без единого простого ответа.
Раньше я был большим поклонником Hibernate после его использования в нескольких проектах за несколько лет. Я полагал, что любой проект должен по умолчанию спящий режим.
Сегодня я не уверен.
Hibernate (и JPA) отлично подходит для некоторых вещей, особенно в начале цикла разработки. Гораздо быстрее добраться до чего-то, работающего с Hibernate, чем с JDBC. Вы получаете множество функций для бесплатного кэширования, оптимистичной блокировки и т.д.
С другой стороны, он имеет некоторые скрытые затраты. Спящий режим обманчиво прост при запуске. Следуйте инструкциям, добавьте некоторые аннотации в свой класс - и у вас есть настойчивость. Но это не просто и уметь писать хороший код в нем требует хорошего понимания как его внутренних разработок, так и дизайна базы данных. Если вы только начинаете, вы можете не знать о некоторых проблемах, которые могут вас укусить позже, так что вот неполный список.
Производительность
Производительность исполнения достаточно хороша, мне еще предстоит увидеть ситуацию, когда спящий режим был причиной низкой производительности в производстве. Проблема заключается в производительности запуска и том, как она влияет на время тестирования устройства и производительность разработки. Когда спящий режим загружается, он анализирует все сущности и делает много предварительного кэширования - это может занять около 5-10-15 секунд для не очень большого приложения. Таким образом, ваш 1 секунда unit test теперь займет 11 секунд. Не весело.
Независимость базы данных
Это очень здорово, если вам не нужно делать точную настройку в базе данных.
Сессия в памяти
Для каждой транзакции Hibernate будет хранить объект в памяти для каждой строки базы данных, к которой он "прикасается". Это хорошая оптимизация, когда вы делаете простой ввод данных. Если вам по какой-то причине нужно обрабатывать множество объектов, это может серьезно повлиять на производительность, если вы явно и тщательно не очищаете сеанс внутри памяти.
Каскады
Каскады позволяют упростить работу с графами объектов. Например, если у вас есть корневой объект и некоторые дети, и вы сохраняете объект root, вы можете настроить спящий режим для сохранения детей. Проблема начинается, когда ваш граф объектов становится сложным. Если вы не будете очень осторожны и хорошо разбираетесь в том, что происходит внутри, вам легко это испортить. И когда вы это делаете, очень сложно отладить эти проблемы.
Lazy Loading
Lazy Loading означает, что каждый раз, когда вы загружаете объект, hibernate не будет загружать все связанные объекты, но вместо этого предоставит владельцам мест, которые будут разрешены, как только вы попытаетесь получить к ним доступ. Отличная оптимизация? Это, за исключением того, что вам нужно знать об этом поведении, иначе вы получите критические ошибки. Google "LazyInitializationException" для примера. И будьте осторожны с производительностью. В зависимости от порядка загрузки объектов и графа объектов вы можете нажать "n + 1 selects problem". Google для получения дополнительной информации.
Обновление схемы
Hibernate позволяет легко изменять схему, просто рефакторинг java-кода и перезапуск. Это здорово, когда вы начинаете. Но тогда вы выпускаете версию 1. И если вы не хотите потерять своих клиентов, вам нужно предоставить им сценарии обновления схемы. Это означает, что нет более простого рефакторинга, поскольку все изменения схемы должны выполняться в SQL.
Представления и хранимые процедуры
Спящий режим требует исключительного доступа для записи к данным, с которыми он работает. Это означает, что вы не можете реально использовать представления, хранимые процедуры и триггеры, поскольку они могут привести к изменениям данных, когда спящий режим не знает о них. У вас могут быть некоторые внешние процессы, записывающие данные в базу данных в отдельных транзакциях. Но если вы это сделаете, ваш кеш будет иметь недопустимые данные. Это еще одна вещь, о которой нужно заботиться.
Однопоточные сеансы
Спящие сеансы однопоточные. Любой объект, загруженный через сеанс, может быть доступен только (включая чтение) только из одного потока. Это приемлемо для приложений на стороне сервера, но может осложнить ненужные вещи, если вы используете приложение на основе графического интерфейса.
Я думаю, моя точка зрения заключается в том, что нет бесплатного питания.
Hibernate - хороший инструмент, но это сложный инструмент, и для его понимания требуется время. Если у вас или членов вашей команды нет таких знаний, проще и быстрее пойти с чистым JDBC (или Spring JDBC) для одного приложения. С другой стороны, если вы готовы вкладывать время в обучение (включая обучение, делая и отлаживая), чем в будущем, вы сможете лучше понять компромиссы.
Спящий режим может быть хорошим, но он и другие ОРС JPA имеют тенденцию диктовать структуру базы данных в определенной степени. Например, составные первичные ключи могут быть выполнены в Hibernate/JPA, но они немного неудобны. Существуют и другие примеры.
Если вам удобно с SQL, я бы настоятельно предложил вам взглянуть на Ibatis. Он может делать 90% + того, что Hibernate может, но намного проще в реализации.
Я не могу придумать ни одной причины, по которой я бы выбрал прямо JDBC (или даже Spring JDBC) над Ибатисом. Hibernate - более сложный выбор.
Взгляните на Spring и учебник Ibatis.
Без сомнения, Hibernate имеет свою сложность.
Но то, что мне действительно нравится в подходе Hibernate (некоторые другие тоже), - это концептуальная модель, которую вы можете получить на Java лучше. Хотя я не считаю OO панацеей, и я не ищу теоретической чистоты дизайна, я так много раз обнаружил, что OO действительно упрощает мой код. Как вы конкретно задали подробности, вот несколько примеров:
сложность добавлена не в модель и сущности, а в вашу структуру для управления всеми объектами, например. Для сторонников жесткой частью является не несколько классов фреймворков, а ваша модель, поэтому Hibernate позволяет вам сохранить твердую часть (модель) самой чистой.
если поле (например, идентификатор или поля аудита и т.д.) используется во всех ваших сущностях, вы можете создать с ним суперкласс. Поэтому:
Hibernate также имеет множество функций для работы с другими характеристиками модели, которые могут вам понадобиться (теперь или позже, добавьте их только по мере необходимости). Возьмите его как качество расширяемости для вашего дизайна.
При повторном использовании между вашими объектами (но только соответствующим наследованием и композиция) обычно есть некоторые дополнительные преимущества. Примеры:
Со временем требования развиваются. Там будет точка, в которой ваша структура базы данных имеет проблемы. При использовании только JDBC любое изменение базы данных должно влиять на код (т.е. Двойную стоимость). С Hibernate многие изменения могут быть поглощены изменением только отображения, а не кода. То же самое происходит и наоборот: Hibernate позволяет вам изменить свой код (например, между версиями), не изменяя вашу базу данных (изменяя отображение, хотя это не всегда достаточно). Подводя итог, Hibernate позволяет независимо развить вашу базу данных и ваш код.
По всем этим причинам я бы выбрал Hibernate: -)
Я думаю, что это прекрасный выбор, но лично я бы использовал спящий режим. Я не думаю, что спящий режим является излишним для проекта такого размера.
Где Hibernate действительно сияет для меня, имеет дело с отношениями между сущностями/таблицами. Выполнение JDBC вручную может занять много кода, если вы имеете дело с одновременным изменением родительских и дочерних элементов (внуков, братьев и сестер и т.д.). Hibernate может сделать это бриз (часто достаточно одного сохранения родительского объекта).
Конечно, существуют сложности при работе с Hibernate, такие как понимание того, как работает очистка сеанса, и работа с ленивой загрузкой.
Hibernate лучшие костюмы для приложений промежуточного программного обеспечения. Предположим, что мы создаем среднюю посуду поверх базы данных. Доступ к среднему средству доступно примерно 20 приложениям, в этом случае мы можем иметь спящий режим, который удовлетворяет требованиям всех 20 приложений.
Прямой JDBC в лучшем случае соответствовал бы самым простым случаям.
Если вы хотите остаться в Java и OOD, тогда ваш Hibernate или Hibernate/JPA или любой другой JPA-провайдер/JPA должны быть на вашем собственном месте.
Если вам более комфортно работать с SQL, то наличие Spring для шаблонов JDBC и других основанных на SQL фреймворков не повредит.
Напротив, помимо управления транзакциями, нет поддержки от Spring при работе с JPA.
... Сессия в памяти... LazyInitializationException...
Вы можете посмотреть Ebean ORM, который не использует объекты сеанса... и где работает ленивая загрузка. Конечно, вариант, а не перебор, и будет проще понять.
В JDBC, если мы открываем соединение с базой данных, нам нужно записать в try, и, если произойдут какие-то исключения, блок catch будет обманывать его и, наконец, использовать для закрытия соединений.
В jdbc все исключения проверяются исключениями, поэтому мы должны писать код в try, catch и throws, но в спящем режиме мы имеем только отмененные исключения
Здесь, в качестве программиста, мы должны закрыть соединение, или мы можем получить сообщение о связях...!
На самом деле, если мы не закрыли соединение в блоке finally, jdbc не отвечает, чтобы закрыть это соединение.
В JDBC нам нужно писать команды Sql в разных местах, после того, как программа создала, если структура таблицы была изменена, тогда программа JDBC не работает, снова нам нужно изменить и выполнить компиляцию и повторное развертывание, что является утомительным.
JDBC используется для генерации кодов ошибок, связанных с базой данных, если произойдет исключение, но java-программисты не знают об этих ошибках правильно.
Пока мы вставляем какую-либо запись, если у нас нет какой-либо конкретной таблицы в базе данных, JDBC будет вызывать ошибку, например "View not exist", и выдает исключение, но в случае спящего режима, если он не найден любая таблица в базе данных создаст для нас таблицу
Поддержка JDBC LAZY loading и Hibernate поддерживает загрузку
Hibernate поддерживает наследование, ассоциации, коллекции
В спящем режиме, если мы сохраним объект производного класса, его объект базового класса также будет сохранен в базе данных, это означает, что поддерживающее спящий режим наследование
Hibernate поддерживает отношения типа "один-ко-многим", "один-к-одному", "много-ко-многим", "много-к-одному"
Hibernate поддерживает механизм кэширования, количество обратных рейсов между приложением и базой данных будет уменьшено, используя эту технику кэширования, производительность приложения будет автоматически увеличена.
Получение разбиения на страницы в спящем режиме довольно просто.
Hibernate имеет возможность генерировать первичные ключи автоматически, пока мы сохраняем записи в базе данных
если миллиарды пользователей, использующих приложение или сеть, а затем в запросе jdbc будут выполняться миллиарды раз, но в запросе на спящий режим будут выполняться только один раз для любого числа пользователей, наиболее важными и легкими преимуществами спящего режима над jdbc.