Комментарии 23
А кто в здравом уме и твердой памяти переезжал на новую БД и ему в этом помогла ОRМ?
Мы переезжали с оракла на ms sql
Переехали без проблем, поменяли драйвер в ORM и переписали три процедуры.
Приложение примерно на 400к строк.
Большей головной болью была миграция данных без остановки работы пользователей, но тут возможность создать два контекста с разными драйверами тоже сыграла свою роль.
Перенесли процедуры (как я уже сказал, их всего несколько штук), переписали какие то диалекто-зависимые вещи. Переключили драйвер, починили, что сломалось.
Потом написали приклад для синхронизации данных, раскатали обновление сервера с новыми параметрами…
Понятно, что не так гладко и быстро все было, но это были человеческие ошибки и какие то особенности системы, которые пожалуй, под nda.
Зачем переезжать? Не надо переезжать. Достаточно иметь необходимость поддержки сразу несколько вариантов баз данных на бакенде. Например MSSQL vs PgSQL vs MySQL ну и до кучи даже SQLite для мелких инсталляций. И все для одного продукта. Разные заказчики в т.ч. исходя из особенностей собственной инфраструктуры могут запросить разные базы. И работать продукт должен одинаково хорошо с каждой из заявленных баз. А вы, граждане-девелуперы, теперь живите с этим… PS: Слава GoFу хоть в пределах одной инсталляции база одна и не меняется и то хорошо.
Всецело поддерживаю идеи статьи. ORM изначально идеологически пошли не туда. Вся эта идея автоматически отобразить манипуляции объектами предметной области на таблицы с помощью какой-то библиотеки была обречена на провал с самого начала. Хотя бы потому, что такое отображение может быть произвольно сложным, как следствие «язык» описания этих отображений должен быть Тьюринг полным. В итоге все ORM это кривые DSL сделанные внутри языков под это не заточенных. Неслучайно самые удачные ORM в динамических языках с богатым мета программированием вроде Ruby и Python. И самые неудачные в куцых языках вроде Java.
И не надо забывать что ORM они тоже разные бывают и что разные ORM имеют свои плюсы и свои минусы.
Я не понимаю вы моей позиции оппонируете или поддерживаете? В вашем тексте ORM можно заменить на что угодно и смысл особо не поменяется...
Я не понимаю вы моей позиции оппонируете или поддерживаете?
Оппонирую. Потому что ORM на мой давно уже достигли вполне себе адекватного уровня и их спокойно себе можно использовать в большинстве случаев. Причём даже в «в куцых языках вроде Java».
И да, бывают те или иные ситуации когда ORM не подходят по той или иной причине. Но тогда и говорить надо что вот в этой ситуации ORM не подходят по причинам X и Y, а не:
Вся эта идея автоматически отобразить манипуляции объектами предметной области на таблицы с помощью какой-то библиотеки была обречена на провал с самого начала
В вашем тексте ORM можно заменить на что угодно и смысл особо не поменяется...
Ну да, ORM в моём тексте можно заменить на любой другой инструмент.
Ага, ясно. Я не говорю, что ORM это плохо и нужно срочно пилить свой маппер или врукопашную с JDBC или ADO.NET. Я вспоминаю начала 2000х, когда выходили статьи вроде «ORM is Vietnam of computer science». Из тех давних времён все виделось так, что база это деталь реализации, а ORM это механизм, который транслирует низкоуровневую базу в высокоуровневую модель предметной области. Под эти идеи и писался hibernate.
Но в итоге дело пришло к тому, что чем ближе модель к БД тем проще жить. А любые попытки сделать объекты, которые загружайся из базы «умными» приводят к множеству проблем. Тем не менее ORM изначально под такой сценарий и затачивались. Вот поэтому я и написал свой комментарий.
Из тех давних времён все виделось так, что база это деталь реализации, а ORM это механизм, который транслирует низкоуровневую базу в высокоуровневую модель предметной области. Под эти идеи и писался hibernate.
Ну вам это виделось так. А кому-то это виделось как простое упрощение работы с базами данных. И возможность спихнуть часть monkey code на эту самую ORM.
Но в итоге дело пришло к тому, что чем ближе модель к БД тем проще жить.
Эээ. Да оно с самого начало вроде бы было ясно что это так. Ну то есть неважно есть у вас ORM или нет, но это всегда останется так.
А любые попытки сделать объекты, которые загружайся из базы «умными» приводят к множеству проблем. Тем не менее ORM изначально под такой сценарий и затачивались.
И я всё ещё не понимаю откуда вы взяли вот это «изначально под такой сценарий и затачивались».
И я всё ещё не понимаю откуда вы взяли вот это «изначально под такой сценарий и затачивались».
Взял я это из жизни :) в 2004 только об этих ORM и о rich domain model были разговоры. Уже упомянутая мной статья, стала своего рода символом этого обсуждения — https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/
Чуть позже Фаулер выпустит книжку, в которой центральным паттерном для сложных систем будет domain model. А центральным способом сохранить и загрузить модель есть Data Mapper. А hibernate и другие ORM есть реализации Data Mapper. Другими словами «Делайте domain model и используйте ORM чтобы ее загружать и сохранять».
И вот что Фаулер пишет про ORM Hate через 8 лет бурных дебатов, в 2012 — https://martinfowler.com/bliki/OrmHate.html
С 2002 до 2012 прошли путь от «ORM позволяет строить красивые доменные модели» к «нафиг это все, давайте anemic model». Далее появился DDD и все поехало по кругу опять, все начали называть свои DAO repository, обсуждать ubiquitous language и bounded context. Где-то пару лет назад начали звучать голоса, что все это как-то сложно. Видимо через ещё пару лет опять anemic будет в фаворе.
И это всё? Да возьмите любую новую технологию/ЯП/фреймворк или что угодно и вы наверняка обнаружите фанатов, которые будут считать что это теперь изменит весь мир. И статьи восторженные найдёте и книги.
Но это же не значит что абсолютно всё это надо воспринимать всерьёз.
Ну да, это все, думаю этого достаточно для поддержки тезиса о том, что на заре своего существования ORM шли немного не туда. А именно в сторону мега тула, который пытается решить все проблемы отображения предметной области в БД. Пришли в итоге к тому, что в БД с их помощью отображается модель, которая 1-в-1 повторяет БД.
Суть Active Record проста: мы храним бизнес-логику с логикой хранения сущности.
Ну уж нифига. Active Record — это и есть хранилище, только не такое плоское, как Repository. Предоставляет для бизнес слоя доступ к данным в более удобной форме, нежели паттерн "хранилище", и инкапсулирует всю логику доступа, хранения изменения данных, экспортируя только консистентные операции.
Просто современные ORM недостаточно гибкие, чтобы раскрыть всю мощь удобства Active Record, ибо не позволяют напрямую управлять хранением из самой entity, а только управляют простыми отношения между сущностями. Объект-сущность в ORM мимикрирует под POJO, хотя таковым не является. Поэтому для более сложных операций вещей потребовался посредний — некий слой, куда можно было бы инъектировать ненавистный EntityManager, и который носит гордой название паттерн "хранилище".
Но это легко исправить: EntityManager доступен в текущем UnitOfWork (а вне ее он вообще не имеет смысла) как правило привязанном к ThreadLocal. Или как альтернатива — ковырнуть generated-поля самого класса Entity (он там тоже есть). И вперед! А все паттерны пусть идут лесом.
Но такое разделение ответственностей не дается бесплатно.
Еще бы! Через некоторое время проект превращается в помойку из копипейщеных слоев, дао, хранилищ и прочей лабуды. А любое изменение как ножом пронизывает насквозь сразу всю эту хваленую луковицу.
Я не знаю, с чего вдруг active record начали антипаттерном.
В Quarkus он вполне себе неплохо себя чувствует и для простейших CRUD'ов удобен: https://quarkus.io/guides/hibernate-orm-panache
Говорят, в Grails он вообще крутой. Сам не пробовал, только доку читал: https://gorm.grails.org/latest/hibernate/manual/index.html
Почему здравый смысл важнее паттернов, а Active Record не так уж и плох