All streams
Search
Write a publication
Pull to refresh
13
0
Сергей Роговцев @lair

Архитектор

Send message
Ну так изменение названия с точки зрения системы мало отличается от удаления столбца — и то, и другое приводит к падению системы.

Просто первый попавшийся пример.
«Бывает и так, но только в том случае, если Вы недостаточно внимания уделили анализу предметной области и проектированию системы.»
Не только. Просто вам везло с заказчиком. В моей практике, когда сначала в анализе бизнес-модели одни данные, а через полгода меняется представитель заказчика — и данные вместе с ним — регулярны.

К сожалению, такова реальность, с ней ничего нельзя поделать.
… у меня есть два места, где есть косяки, и два места, где я могу улучшить.

«если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк. „
Очень важное слово “если».

Возвращаясь к началу треда: иллюзия «все супер» есть (или нет) в обоих случаях, не надо приписывать ее только ORM.
А вы это полагаете, полагаю, исключительно из теоретических соображений? А как это реально обосновать?
«вы утверждаете, что при использовании ООП и соответствующей прослойки любая БД — это ООБД»
Я этого не утверждаю. Я говорю, что недостаток «предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются» равно присущ как ORM+RDBMS, так и ООБД (и чистым RDBMS тоже, кстати).

Теория — это хорошо, но в теории ORM, например, генерит «чистый код».

Нам интереснее практика.
Похоже, вы не уловили посыла.

Смысл в следующем: для получения данных из ORM over RDBMS и для получения данных из ООБД я как программист выдаю более-менее одинаковый код. В обоих случаях я, как программист, думаю, что система, с которой я работаю, делает «все супер», и заморачиваться не надо.

При этом что ООБД, что ORM легко могут все изгадить, но я, как программист, никакого контроля над этим не имею.
Вот лично вы знаете, во что ООБД преобразует объектную модель для хранения на диске?

Так что это тоже видимость объектной модели, просто поверх какого-то другого хранилища. И преобразование, очевидно, тоже есть.
А вот вы подумайте с точки зрения разработчика: ему ли не пофиг, вызвал он метод ORM, вернувший набор объектов по заданному критерию, или же вызвал он метод ООБД-провайдера, вернувший тот же набор объектов по тому же критерию?

В обоих случаях мы дернули черный ящик, получили результат, только в первом случае черный ящик состоит из двух известных нам слоев (ORM — RDBMS), а в другом — из одного (ООДБ, причем какая у нея внутре неонка, мы не знаем).
… можно подумать, ООБД не делает того же самого.

Поясню: ООБД дает разработчику видимость хранения объектной модели. Разработчик думает, что все супер. Но беда в том, что никто не знает, насколько все супер, и что с этим делать.

В этом отношении ОРМ и ООБД совершенно идентичны (а ООБД, как закрытая система, еще и хуже).

Мораль: что ОРМ, что ООБД просто надо тестировать под нагрузкой. И выбирать по результатам.
Беда в том, что все эти вещи — language-specific. Как следствие, практически невозможно создать ООБД, независящую от языка разработки — в то время как для RDBMS существует стандарт де-факто в виде SQL, являющегося языком-посредником.

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

С ORM все как раз понятно — хорошо сделанный ORM объединяет максимум достоинств RDBMS и ООП. А вот в ООБД с первым обычно тяжело и плохо.
Согласен, в случае хорошей ООБД — да.
Для проверки валидности модели там, где эта проверка включена, нужен доступ к базе. На билд-сервере обычно.
«Согласен на все 100%. ORM и прочие прослойки — это зло.»
Аргументируйте. Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло. А то как бы вы сейчас вообще отвергаете идею разделения слоев.
«Есть очень много плюсов при их использовании, однако, в противовес им появляются и недостатки, которые я описал»
Это верно для любого инструмента. Я просто указал на забытый вами плюс. А минусы у них планомерно изживаются.

«Вообще в хорошо спроектированной системе не должны менять названия полей в базе. „
Чтобы система была хорошо спроектирована, в ней не должны меняться требования. Беда в том, что в реальной жизни требования меняются (иначе бы не было культа рефакторинга). А раз меняются требования, то и структура данных может меняться.
Зря сомневаетесь. Валидация модели в компайл- (или тест-) тайме — нормальная практика. Да, после проваленной валидации придется править руками. Но мы узнаем об этом не из юнит-теста (в лучшем случае), а из валидатора модели, который конкретно скажет, что где не совпадает.
Что касается ORM: вы забыли одну простую вещь — хорошая ORM уменьшает затраты на поддержку приложения, поскольку позволяет автоматически или полуавтоматически отслеживать изменения СУБД и кода. Иными словами, используя хорошую ORM мы избавлены от проблемы «в базе поменялось название поля — система молча упала».
Внимание, вопрос: чем этот корпус отличается от, скажем Antec Nine Hundred, которому уже несколько лет?

(а еще интереснее, конечно, чем он лучше)
От Parole — слово.
Они сами напрямую не продают, поэтому цены — в магазинах (читай — price.ru)

Information

Rating
Does not participate
Location
Montreal, Quebec, Канада
Date of birth
Registered
Activity