Интегрируется ли ORM с существующими приложениями или я не понимаю?

Question

Предположим, Hibernate для ORM.

Я не уверен, как это спросить. Я хочу создать приложение, которое может заменить часть другого. Например, скажем, у меня есть приложение с различными модулями, которое называется «большое» приложение. Это приложение может обрабатывать HR, финансы, покупки, наборы навыков и т. Д. Но, возможно, по какой-то причине мне не нравится модуль набора навыков, но мне нравится остальная часть приложения. Я хочу создать приложение, использующее ту же базу данных, что и остальные «большие» приложения, но использую мое программное обеспечение в качестве внешнего интерфейса для этого компонента.

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

Вот еще один пример. У меня есть устаревшее приложение и устаревшая база данных. Он использует базу данных X. Я решил, что мне больше не нравится старое приложение эмулятора терминала, которое используется для получения данных, и что мне нужна графическая версия. Я могу использовать hibernate с моим приложением, и когда я, наконец, решу избавиться от устаревшей базы данных и перейти на последнюю версию Oracle или SQL Server, я смогу сделать это с минимальной головной болью? Или моя база данных так сильно изменится, что это все равно не будет иметь значения (я полагаю, что при переходе на новую базу данных будет захвачено больше информации)?

Я надеялся на комментарии, если я неправильно понимаю, почему hibernate / ORM может или не может быть преимуществом.

Спасибо.

Answer 1

Я не думаю, что вы получите огромную выгоду от гибернации, если схема базы данных изменится на нечто совершенно иное, вам, возможно, придется изменить больше, чем просто ваше отображение - особенно если в базу данных будет добавлено больше «структуры» (таблицы, колонка и подобные схемы вещей). Тем не менее, если база данных была структурирована в основном таким же образом, но, скажем, меняются только имена столбцов и таблиц, а пара таблиц объединяется или что-то в этом роде - вы можете обойтись, просто изменив свое отображение.

Но я бы действительно рекомендовал использовать hbernate для независимости от базы данных, это довольно простой путь.

И то, что это не поможет вам, если вся ваша база данных будет изменена, это такое невероятное количество других сил, что я выбрал бы это вместо прямого доступа к БД в большинстве случаев.

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

Answer 2

Переключение с одной СУБД на другую (в частности, Oracle на SQL Server) - это то, что использование ORM, безусловно, сделает намного проще.

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

Answer 3

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

Так что, рассматривая ORM, я бы не слишком беспокоился о таких вещах, как приложения "уход" или изменение СУБД (если об этом уже не говорилось, или есть история этого в вашей компании). Я не говорю, что это не вещи, которые никогда не произойдут, а скорее то, что они должны отойти на второй план от более важных соображений в отношении удобства обслуживания, производительности и производительности разработчиков.

Короче говоря, выберите ORM, основываясь на его способности решать проблемы и удовлетворить требования, которые у вас есть сегодня.

Answer 4

Вы можете создавать доменные объекты с помощью Hibernate Tools, если вы это сделаете, это будет безболезненно и быстро. однако если вы напишите все объекты от руки, вы умрете. я думаю, что это хорошая идея, чтобы переписать часть приложения и лучше узнать hibernate.