ORM в реальном мире

Question

Я начинаю новый проект, который, я думаю, продлится несколько лет. Я нахожусь в точке принятия решения об использовании инфраструктуры ORM (или о том, следует ли вообще ее использовать). Может кто-нибудь с опытом сказать мне, используются ли платформы orm в приложениях реального мира. Проблема, которую я имею в виду, заключается в следующем: инструмент orm будет генерировать для меня таблицы, столбцы и т. Д., Когда я создаю и изменяю свои сущности. Однако после того, как проект будет запущен и запущен, некоторые изменения в базе данных будут невозможны. Может ли это помешать продвижению проекта. Если бы я использовал фреймворк, такой как, например, ibatis, я знаю, что мне нужно было бы только корректировать операторы sql на основе изменений базы данных. Может кто-нибудь сказать мне, выжили ли инструменты ORM в реальной среде. В моем офисе мы используем ERP на основе Java, что было сделано давно, и никогда не было сделано с помощью какой-либо платформы ORM.

С уважением. Джош

Answer 1

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

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

Сопоставители объектов, такие как IBatis и EclipseLink , являются безопасным выбором, поскольку они позволяют отображать практически все, обеспечивая возможность создания как великолепной модели предметной области, так и изящной схемы.дизайн.Также обратите внимание, что Spring JDBC прошел очень долгий путь (в частности, очень удобный SimpleJDBCTemplate ), поэтому, хотя технически не является ORM, он позволяет вам делать все, что вы хотите, без написания утомительноСтандартный код JDBC.

Answer 2

ORM очень широко используются в реальных приложениях. Упомянутая вами проблема изменения схемы обычно решается одним из двух способов:

1. Как указывалось в предыдущих ответах, вы можете поддерживать схему вручную в базе данных и заставить ORM обновить свою схему, чтобы она соответствовала тому, что она видит в базе данных.

2. Вы можете заставить ORM проверить схему базы данных на основе собственной информации об объектной модели и сгенерировать необходимые запросы для обновления в случае каких-либо изменений.

По моему опыту, любой приличный ORM должен быть в состоянии справиться с # 1, и большинство, похоже, сможет справиться с # 2, но это не так универсально.

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

Если ваш основной интерес связан с базой данных, и вы используете ORM для обеспечения OO-оболочки вокруг таблиц и полей, чтобы сделать их более доступными, то вам, вероятно, захочется перейти к # 1 и сохранить полный контроль над базы данных.

Если, с другой стороны, вы рассматриваете объектную модель как высшую и в основном используете базу данных в качестве механизма тупого постоянства, а ORM служит для упрощения этой задачи, то вам, вероятно, захочется использовать № 2, чтобы вы может сосредоточиться на объектной модели и не беспокоиться о деталях базы данных. Или вы можете захотеть взглянуть на хранилища ключей / значений, механизмы сохранения графов объектов или другие формы баз данных NoSQL, чтобы получить лучшую поддержку для простого сохранения объектов, не беспокоясь об изменениях схемы на стороне базы данных вообще.

Answer 3

Я уже несколько лет использую в производстве Hibernate + JPA. Я никогда не полагался на генерацию схемы ORM, и думаю, что в целом это плохая практика, так как вы не полностью управляете схемой, и ORM не всегда генерирует оптимальную схему. Использование чего-то вроде Liquibase для отслеживания миграций схемы в гораздо лучшей идее IMO.

Answer 4

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

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