«Бывает и так, но только в том случае, если Вы недостаточно внимания уделили анализу предметной области и проектированию системы.»
Не только. Просто вам везло с заказчиком. В моей практике, когда сначала в анализе бизнес-модели одни данные, а через полгода меняется представитель заказчика — и данные вместе с ним — регулярны.
К сожалению, такова реальность, с ней ничего нельзя поделать.
«вы утверждаете, что при использовании ООП и соответствующей прослойки любая БД — это ООБД»
Я этого не утверждаю. Я говорю, что недостаток «предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются» равно присущ как ORM+RDBMS, так и ООБД (и чистым RDBMS тоже, кстати).
Теория — это хорошо, но в теории ORM, например, генерит «чистый код».
Смысл в следующем: для получения данных из ORM over RDBMS и для получения данных из ООБД я как программист выдаю более-менее одинаковый код. В обоих случаях я, как программист, думаю, что система, с которой я работаю, делает «все супер», и заморачиваться не надо.
При этом что ООБД, что ORM легко могут все изгадить, но я, как программист, никакого контроля над этим не имею.
А вот вы подумайте с точки зрения разработчика: ему ли не пофиг, вызвал он метод ORM, вернувший набор объектов по заданному критерию, или же вызвал он метод ООБД-провайдера, вернувший тот же набор объектов по тому же критерию?
В обоих случаях мы дернули черный ящик, получили результат, только в первом случае черный ящик состоит из двух известных нам слоев (ORM — RDBMS), а в другом — из одного (ООДБ, причем какая у нея внутре неонка, мы не знаем).
Поясню: ООБД дает разработчику видимость хранения объектной модели. Разработчик думает, что все супер. Но беда в том, что никто не знает, насколько все супер, и что с этим делать.
В этом отношении ОРМ и ООБД совершенно идентичны (а ООБД, как закрытая система, еще и хуже).
Мораль: что ОРМ, что ООБД просто надо тестировать под нагрузкой. И выбирать по результатам.
Беда в том, что все эти вещи — language-specific. Как следствие, практически невозможно создать ООБД, независящую от языка разработки — в то время как для RDBMS существует стандарт де-факто в виде SQL, являющегося языком-посредником.
Вот мы и уперлись в то, почему хороших ООБД не будет еще долго.
«Согласен на все 100%. ORM и прочие прослойки — это зло.»
Аргументируйте. Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло. А то как бы вы сейчас вообще отвергаете идею разделения слоев.
«Есть очень много плюсов при их использовании, однако, в противовес им появляются и недостатки, которые я описал»
Это верно для любого инструмента. Я просто указал на забытый вами плюс. А минусы у них планомерно изживаются.
«Вообще в хорошо спроектированной системе не должны менять названия полей в базе. „
Чтобы система была хорошо спроектирована, в ней не должны меняться требования. Беда в том, что в реальной жизни требования меняются (иначе бы не было культа рефакторинга). А раз меняются требования, то и структура данных может меняться.
Зря сомневаетесь. Валидация модели в компайл- (или тест-) тайме — нормальная практика. Да, после проваленной валидации придется править руками. Но мы узнаем об этом не из юнит-теста (в лучшем случае), а из валидатора модели, который конкретно скажет, что где не совпадает.
Что касается ORM: вы забыли одну простую вещь — хорошая ORM уменьшает затраты на поддержку приложения, поскольку позволяет автоматически или полуавтоматически отслеживать изменения СУБД и кода. Иными словами, используя хорошую ORM мы избавлены от проблемы «в базе поменялось название поля — система молча упала».
Просто первый попавшийся пример.
Не только. Просто вам везло с заказчиком. В моей практике, когда сначала в анализе бизнес-модели одни данные, а через полгода меняется представитель заказчика — и данные вместе с ним — регулярны.
К сожалению, такова реальность, с ней ничего нельзя поделать.
«если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк. „
Очень важное слово “если».
Возвращаясь к началу треда: иллюзия «все супер» есть (или нет) в обоих случаях, не надо приписывать ее только ORM.
Я этого не утверждаю. Я говорю, что недостаток «предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются» равно присущ как ORM+RDBMS, так и ООБД (и чистым RDBMS тоже, кстати).
Теория — это хорошо, но в теории ORM, например, генерит «чистый код».
Нам интереснее практика.
Смысл в следующем: для получения данных из ORM over RDBMS и для получения данных из ООБД я как программист выдаю более-менее одинаковый код. В обоих случаях я, как программист, думаю, что система, с которой я работаю, делает «все супер», и заморачиваться не надо.
При этом что ООБД, что ORM легко могут все изгадить, но я, как программист, никакого контроля над этим не имею.
Так что это тоже видимость объектной модели, просто поверх какого-то другого хранилища. И преобразование, очевидно, тоже есть.
В обоих случаях мы дернули черный ящик, получили результат, только в первом случае черный ящик состоит из двух известных нам слоев (ORM — RDBMS), а в другом — из одного (ООДБ, причем какая у нея внутре неонка, мы не знаем).
Поясню: ООБД дает разработчику видимость хранения объектной модели. Разработчик думает, что все супер. Но беда в том, что никто не знает, насколько все супер, и что с этим делать.
В этом отношении ОРМ и ООБД совершенно идентичны (а ООБД, как закрытая система, еще и хуже).
Мораль: что ОРМ, что ООБД просто надо тестировать под нагрузкой. И выбирать по результатам.
Вот мы и уперлись в то, почему хороших ООБД не будет еще долго.
С ORM все как раз понятно — хорошо сделанный ORM объединяет максимум достоинств RDBMS и ООП. А вот в ООБД с первым обычно тяжело и плохо.
Аргументируйте. Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло. А то как бы вы сейчас вообще отвергаете идею разделения слоев.
Это верно для любого инструмента. Я просто указал на забытый вами плюс. А минусы у них планомерно изживаются.
«Вообще в хорошо спроектированной системе не должны менять названия полей в базе. „
Чтобы система была хорошо спроектирована, в ней не должны меняться требования. Беда в том, что в реальной жизни требования меняются (иначе бы не было культа рефакторинга). А раз меняются требования, то и структура данных может меняться.
(а еще интереснее, конечно, чем он лучше)