ORM в реальном
Я начинаю новый проект, что я думаю, будет длиться в течение нескольких лет. Что касается решения платформы ORM для использования (или использовать ли один вообще). Может любой с опытом говорить мне, используются ли orm платформы в реальных приложениях. Проблема, которую я имею в виду, является этим: orm инструмент генерирует для меня таблицы и столбцы и т.д., поскольку я создаю и изменяю свои объекты. Однако после того, как проект пошел живой и работает, определенные изменения базы данных не будут возможны. Может это препятствовать продвижению проекта. Если бы я использовал платформу как ibatis, например, я знаю, что должен был бы только скорректировать sql операторы на основе изменений базы данных. Может кто-то говорить мне, пережили ли инструменты ORM продуктивную среду. В моем офисе мы используем Java базирующийся ERP, который был сделан давно, и он никогда не делался с помощью любой платформы ORM.
С уважением. Josh
4 ответа
Используйте только автоматически сгенерированные схемы для ранней разработки и прототипирования. Сгенерированный DDL почти никогда не удовлетворит опытных администраторов баз данных. Кроме того, база данных будет жить дольше, чем текущий код приложения, поэтому время, потраченное на ее разработку, обычно стоит затраченных усилий.
При выборе картографа выбирайте гибкий и избегайте одержимых объектами картографов, поскольку они часто поддерживают только ограниченную настройку базы данных. На ум приходит плохая интеграция хранимых процедур в режиме гибернации, равно как и отсутствие поддержки в JPA для преобразователей настраиваемых типов.
Устройства сопоставления объектов, такие как IBatis и EclipseLink , являются безопасным выбором, поскольку они позволяют отображать практически все, что дает вам возможность создать как отличную модель предметной области, так и изящный дизайн схемы. Также обратите внимание, что Spring JDBC прошел очень долгий путь (в частности, очень удобный SimpleJDBCTemplate ), поэтому, хотя технически он не является ORM, он позволяет вам делать все, что вы хотите, без утомительного написания Стандартный код JDBC.
Я уже несколько лет использую в производстве Hibernate + JPA. Я никогда не полагался на создание схемы ORM, и я думаю, что это плохая практика в целом, поскольку вы не полностью контролируете схему таким образом, и ORM не всегда будет генерировать оптимальную схему. Использование чего-то вроде Liquibase для отслеживания миграций схемы в намного лучшей идее IMO.
ORM очень широко используются в реальных приложениях. Проблема изменения схемы, о которой вы упомянули, обычно решается одним из двух способов:
Как было предложено в предыдущих ответах, вы можете поддерживать схему в базе данных вручную, а ORM обновлять свою схему в соответствии с тем, что он видит в базе данных.
Вы можете заставить ORM сверять схему базы данных со своей собственной информацией об объектной модели и генерировать необходимые запросы для обновления, если произошли какие-либо изменения.
По моему опыту, любой приличный ORM должен уметь работать с #1, а большинство, похоже, умеют работать с #2, но это не совсем универсально.
Что касается того, что лучше, ну... Это во многом зависит от того, как вы рассматриваете отношения между вашей базой данных и вашей объектной моделью.
Если ваш основной интерес - база данных, и вы используете ORM для обеспечения OO-обертки вокруг таблиц и полей, чтобы сделать их более доступными, тогда вы, вероятно, захотите выбрать #1 и сохранить полный контроль над базой данных.
Если, с другой стороны, вы рассматриваете объектную модель как нечто высшее и используете базу данных в основном как тупой механизм сохранения, а ORM служит для упрощения этой задачи, то вы, вероятно, захотите использовать #2, чтобы сосредоточиться на объектной модели и не беспокоиться о деталях базы данных. Или вы можете обратить внимание на хранилища ключей/значений, механизмы сохранения объектных графов или другие формы NoSQL баз данных, чтобы получить лучшую поддержку прямого сохранения объектов без необходимости беспокоиться об изменениях схемы на стороне базы данных.
Я использую Hibernate несколько лет и очень им доволен. Я использую генератор схемы только для создания новой базы данных, но для обновлений я использую созданные человеком сценарии sql.
Я не думаю, что можно надежно автоматизировать обновление схемы: например, если вы переименуете поле, автоматический инструмент удалит это поле и добавит новое, что приведет к потере содержимого.