Обсуждаем ORM

[Paramedic]

Есть такая специальность???

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

Ну а при чем тут вопросы чайников которые пытаются видимо изучать в иституте программирование и им попался вопрос по орм в котормо оно ни бум-бум? В тырнете полно глупых вопросов. И что? На развитие технологий и их использование они никак не влияют.

Да потому, что это вопросы не чайников. А вопросы людей, понявших, что ORM это не совсем то, о чём им пытаются рассказать восхищённые адепты. И что в рамках реляционного подхода они бы давно задачу выполнили.

Да, это задача ОРМ, для этого он и используется.Так поручите программеру. Кторый сумеет правильно запрограммить ORM а не просто взять у архитектора описание структур и закодить их на выбранном языке программирования.

Задача ORM однозначно соотнести объекты программы и записи в RDBMS.

И, как ни странно, БД тоже требуют проектирования, и разработки. И нафига здесь лишнее звено в виде ORM?

И мы ещё недообсудили кражу БД. В случае с реляционным подходом это невозможно. В случае с ORM подходом это делается на раз.

[Кувалдыч ТС]

. Вот простейший пример, когда ORMщики вместо работы ищут ответы на свои вопросы:

https://forum.kohanaframework.org/discussion/11574/orm-uncompress-vo-vremya-izvlecheniya-Иli-voobsche-

"Можно ли как-то через ORM извлекать данные, которые были записаны через COMPRESS () в mysql в BLOB?" - аа кто проектировал БД и почему за нее отвечает не ОРМ?

Причём опять же сделали это через жопу.

Ну так все через жопу... зачем в базу писали не через ОРМ?

Это и есть геморрой.

Тока связанный не с ОРМ, а с кривой архитектурой уровня данных.

Да я уже постил ссылку. Повторюсь:

Опять же кривость рук... в ОРМ совсем не обязательно тянуть хвосты, это раз. Во вторых, ОРМ редко когда предназначена для частых запросов. Ибо в ней чаще всего реализуется принцип "чтение пачкой в совокупном итоге быстрее чем по одиночке". Т.е. это кривость архитектуры, в том числе и построенного теста, ибо он не учитывает совокупную производительность подсистемы, а только ее узкий случай.

с избыточным обращением к метаданным. Вызванный тем, что моделям требуется знать атрибуты таблицы.

Ессно. Это плата за универсальность.
Когда пишешь просто запрос, то затачиваешь его под конкретные типы данных. Теряешь универсальность, выигрываешь в скорости, ибо меньше кода и запросов.
Однако, в нормальнйо ОРМ системе применяется разовая сборка запросов, и при этом первый запрос идет долго, зато все последующие запросы срабатывают так же быстро как и обычные.

 

ORM технология не годная?

Годная, но бессмысленная. Нет смысла тратить столько ресурсов разработчика на систему моделей ОРМ в которой практически ничего не меняется со временем. Преимущество ОРМ как раз в том что она дает огромный выигрыш  стоимости разработок где предметная область часто меняется или уточняется, или где требуется универсальность по отношению к базам данных.

А про движок вообще.

Движки форумов или движки чего попало? На мотоциклах и тракторах разные движки. И никому в голву не приходит ставить одно вместо другого или ругать движки мотиков на тракторах.

примеры задач с хорошей изоляцией?

Не задач, а решений? Ну тот же файсбук или вконтакте.

за два дня написать с использованием ORM клиента?

Еще раз... ОРМ не используется на уровне презентаций или бизнеслогики.
Клиенты на нем не пишутся. ОРМ используется только в уровне данных, между уровнем данных и уровнем бизнес-логики.

Задача ОРМа - сохранять и извлекать данные в виде обхектов бизнес-логики. Это ен задача уровня сервисов или презентации.


Как пример, где ОРМ отлично решает свои задачи и дает огромные преимущества - это разработка заказных систем и фреймворков для близких предметных областей. Когда у заказииков разные сервера данных, когда впроде и область знаний та же, а у каждого свою исторические и прочие нюансы и они не готовы от них отказаться, но и переплачивать за разработку не хотят.

[Кувалдыч ТС]

Задача ORM однозначно соотнести объекты программы и записи в RDBMS.

Именно. Поэтому приведенный пример высосанной проблемы с БЛОБОМ отношения к ОРМ не имеет.

И нафига здесь лишнее звено в виде ORM?

Оно не лишнее, оно замещающее. При использовании ОРМ отпадает необходимость в проектировании БД. Потому что объектная модель данных строится в системе ОРМ, а не с СУБД.

В случае с реляционным подходом это невозможно.

Да ладно. И кто там мешает?

В случае с ORM подходом это делается на раз.

Как?

И в чем отличие кражи СУБД от ОРМ?

[Кувалдыч ТС]

Поскольку у компа я наверно  появлюсь тока завтра, даю "домашнее задание":

Переведем вот это:

И мы ещё недообсудили кражу БД. В случае с реляционным подходом это невозможно. В случае с ORM подходом это делается на раз.

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

"Мы еще не дообсудили угон ежа Кувалдыча. В случае отсуствия гаража это невозможно. В случае с гаражем это делается на раз".

Вопрос:
"Как угнать ежа Кувалдыча из гаража, если этого ежа в гараже никогда не было и не будет?"

Подумай... ответы ведь очевидны.
И они теже самые что ответы про воровство СУБД напрямую, через ОРМ и ДТО.
Это три изолированные друг от друга стенки на пути взломщика.
Ессно через одну пробиться намного проще. При этом если в ней уже найдена дыра, то через нее можно обойти мимо все другие внешнеи стены. Ну а украть базу из слоев где никогда всей базы и не бывает... невозможно украть то чего там нет

[Paramedic]

Подумай... ответы ведь очевидны.

Ну давай подумаем.

Итак, имеем нечистоплотного разработчика.

Так же имеем БД в РСУБД PostgreSQL. Впрочем, не суть. Хоть в Oracle. У БД есть администратор БД. На стороне сервера БД пишутся хранимые процедуры, которые возвращают наборы данных DataSet. Эти процедуры напрочь скрывают от нечистоплотного разработчика структуру БД. Разработчик даже не ведает, что зачастую, происходит объединение нескольких таблиц, а так же используются аггрегаторы UNION (кстати, напрочь не доступные в ORM). Разработчик ограничен только данными, которые администратор БД счёл нужным этому разработчику предоставить. Всё. Кража БД напрочь невозможна. Возможна утечка некоторых данных, и то, скорее всего, эти данные итак будут публичными.

Теперь возьмём ORM. Нечистоплотный разработчик имеет полный доступ к БД, и её метаданным.

Ты говоришь, не нужно использовать ORM во фронтенде. Хорошо. Нечистоплотный разработчик уведёт БД при программировании  сервиса ДТО.

Я всё верно мыслю?

[Paramedic]

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

Я уже говорил, что работал с ORM до появления термина ORM. А так же работал с ORM после глубокого освоения SQL. Моё мнение -- что ORM это такая технология, которая в угоду якобы быстроте разработки приносит в жертву скорость и надёжность. И самое смешное, затрудняет разработку, и увеличивает на неё затраты.

Патамушта вместо расово верного программирования всё пытаются технологии внедрить, для облегчения этого труда. Чтобы писать быстро. Раззз, и готово. В результате на освоение технологий уходит куча времени. А некоторые технологии являются говнотехнологиями изначально. Например, та же ORM.

Ты утверждаешь, что ORM это удобно.

Но я не вижу ни одного аргумента в пользу того, что это удобно.

Хотелось бы эти аргументы увидеть. А не пространные размышления о том, как надо программировать вообще.


Я прошу показать мне те преимущества, которые появятся в арсенале программиста после освоения ORM. Ну кроме того, что теперь SQL учить не нужно.

[Paramedic]

Позволю себе ещё пару ссылок.

1. http://citforum.ru/database/articles/vietnam/

Очень годная переводная статья, хоть и содержит многабукаф. Для неспешного, вдумчивого чтения.

2. http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Тоже годная статья. Правда не переведена. Основная мысль: "ORM кажется неплохой идеей вначале, а когда проблемы становятся очевидными, слишком поздно, чтобы сматывать удочки."

[OVA]

Однозначно от лукавого.
SQL, не смотря на существующий стандарт,  и тот реализуется в СУБД в каждой со своими вариациями. Уж куда более востребованная вещь!
А тут бред бредовый какой-то.

[Кувалдыч ТС]

Эти процедуры напрочь скрывают от нечистоплотного разработчика структуру БД. Разработчик даже не ведает, что зачастую,

Однако при этом разработчик имеет доступ к соединению с БД, а значит может выполнить ЛЮБОЙ запрос и получить ЛЮБЫЕ данные.
В отличии от архитектуры с выделенным слоем данных, например ОРМ. Где разработчик не имеет соединения с БД, а значит физически ен может получить то, что ему не дает ОРМ.

Нечистоплотный разработчик имеет полный доступ к БД, и её метаданным

Не имеет. Только к классам моделям.

Нечистоплотный разработчик уведёт БД при программировании  сервиса ДТО.

Не уведет. У него нет на этом уровне доступа к БД, в отличии от скл-программера.
На данном уровне разработчик или злоумышленник имеет длступ только к моделям бизнес-логики и то только с теми правами которые ему даны в соотвествии с его ролями.

А тут бред бредовый какой-то.

В статьях? Лень читать.

тот реализуется в СУБД

Не.. скл реализует язык запросов в СУБД. А структура СУБД строится CASE-средствами.

Так вот, ОРМ по сути является гибридом скл и кейс средства. ОРМ позволяет проектировать и одновременно реализовывать уровень данных абстрагируясь от его источника. Так же ОРМ позволяет ввести еще один уровень безопасности над данными (кроме той что возможна на источнике), при чем сделать это более гибко, ибо ОРМ модели являются программными можелями, а значит могут реализовать абсолютно любой алгоритм предоставления доступа, вплоть до значений атрибутов.

[OVA]

реализовывать уровень данных абстрагируясь от его источника

Для этого и так существует до фига средств.
Например, в архитектуру проекта закладываются программные интерфейсы, с привязкой к которым достаточно породить тот или иной реальный объект (которые разрабатываться могут совсем другими группами разработчиков - регламентируются только методы интерфейсов, их входные и выходные параметры), который реально будет оперировать с данными ниже него.
В самой БД реализуется бизнес-логика на триггерах и хранимках, юзеру запрещается на уровне базы лазить в таблицы напрямую и разрешают доступ только к некоторым объектам как то хранимые процедуры и/или функции.
Словом, любой серьёзный SQL-сервер в связке с любым современным ООЯП, который в свою очередь может гибко описать объектную модель, позволяет абстрагировать доступ к данным достаточно серьёзно.
Тот или иной инструментарий абстрагирования встроен, не побоюсь предположить, в любую ERP-систему корпоративного уровня. Но ратовать за повсеместное использование ORM и вздымать знамя до небес я б не стал.
Как у любой технологии, у неё просто есть своя ниша.

[Кувалдыч ТС]

Возмем абстрактный пример.

Допустим у нас одноуровневое приложение.
Т.е. фронтенд напрямую обращается в БД и генерит на ее основе страницы.

Это значит что внедрившись во фронтенд, самую незащищенную часть приложения, мы имеем ПОЛНЫЙ доступ к БД. Можем закачать ее хоть всю. При чем вместе с метаданными, так как в любой СУБД можно строить запросы к скрытым служебным таблицам описывающим структуру БД. Т.е. спереть БД целиком тут просто как нефиг делать. Нужно лишь проникнуть во фронтенд.


Берем теперь многоуровневую структуру приложения.
Допустим мы проникли через фронтенд. Оттуда соотвесвенно есть доступ к уровню сервисов.
Сервисы это ограниченый набор функций и объектов передачи данных (ДТО модели) юизнес-логики необходимый для работы фронтенда или сопрягаемых приложений. Плюс к тому же уровень сервиса реализует ролевое разделение доступа к функциям. Что усложняет жизнь злоуишленника. Итого, данные своровать в этом месте очень сложно, и то далеко не все данные отсюда доступны.

Но если очень надо украсть... придется проникать непосредственно в консоли серверов или устроиться на работу к жертве, дабы получить доступ хотя бы в коды уровня сервисов. Допустим это удалось. В уровне сервисов доступнен уровень бизнес-логики. Т.е. библиотеки классов бизнес-модели, взаимосвязи между ними, действия с ними. Пр чем опять же все это снабжено ролевым разделенем доступа, ибо к примеру атрибут "зарплата" у класса "работник" может читать "Владелец, Руководитель, Бухгалтер", а писать только "Руководитель". Атрибут "Список задач" у того же класса к примеру "Бухгалтер" вообще не видит. Так же злоумышленник даже имея в распоряжении какую либо роль, все равно не может получить ВСЕ данные. Только частично. Не говоря уже о том, что в БД могут быть и другие данные, кторые тупо не отражены в объектах бизнес-модели. В общем тут тоже облом.

Злоумышленнику остается два пути - либо просить жертву о переводе вна работу с уровнем данных, либо каком-то образом получить максимум возможных ролей в приложении. А еще лучше "суперроль" которой можно все хотя бы читать. Правда все равно это будет не вся база, а только ее часть, которая имеет отражение в бизнес-моделях.

Собственно, для упрощения структуры, бизнес-модели могут быть реализованы и технологией ОРМ. Это ничего не меняет кроме того, что вместо двух разных библиотек классов для уровня данных и уровня бизнес-логики, будет одна единая библиотека. В простых приложениях это проще и удобно. В больших часто наборот очень усложняет жизнь, так как там существует приличная разница в структуре моделей уровня данных, заточенных под данные и структуре моделей уровня бизнес-логики, заточенной под бизнес-алгоритмы.


Ну так вот, даже тупо по числу букв в описании как красть БД в одноуровневом приложении с прямым доступом к СУБД через СКЛ и нормально спроектированным многоуровневым приложением. Очевидно, что во втором случае "своровать БД" на несколько порядков сложнее, дольше и геморнее.

И это мы еше не затронули темы вертикального и горизонтального масштабирования. Т.е. наращивания производительности системы. В многоуровневом варианте это делается дешевле и эффективнее, ибо оптимизировать и масштабировать можно отдельно взятые уровни, в зависимости от того, на каком уровне есть узкие места с нагрузкой.

[Paramedic]

Однако при этом разработчик имеет доступ к соединению с БД, а значит может выполнить ЛЮБОЙ запрос и получить ЛЮБЫЕ данные.

Нет. Не может. У разработчика свой логин/пароль. У DBA другой. DBA выдал права только на исполнение, скажем, двух хранимых процедур. Всё.

Ты признаёшь, что через ORM база крадётся, а через классический подход -- нет?

[Paramedic]

Не имеет. Только к классам моделям.

Класс это проекция таблицы на объект. Более того, ORM не может работать без метаданных. ORM обязан знать все поля в таблице, даже если используется всего два. Таким образом образом, всё-таки доступ имеет.

[Кувалдыч ТС]

Для этого и так существует до фига средств.

Никто ине спорит. ОРМ одно из них.

в архитектуру проекта закладываются программные интерфейсы, с привязкой к которым достаточно породить тот или иной реальный объект (которые разрабатываться могут совсем другими группами разработчиков

Да так оно и есть. Именно так проектируются сложные приложения. Вот только програмные интерфейсы не могут спроетировать хранилище. Только описать взаимодействие модклей приложения между собой. А мы говорим о хранилищах.

В самой БД реализуется бизнес-логика на триггерах и хранимках

Ага... в прошлом веке так и делали. До сих пор расхлебываем ))

юзеру запрещается на уровне базы лазить в таблицы напрямую и разрешают доступ только к некоторым объектам как то хранимые процедуры и/или функции.

Да, одна из старинных технологий.  До сих пор часто используется, в иду того, что раньше ничего другого и не было, и часто сама СУБД имеля функционал позволяющий выполнять часть бизнес-задач. В частности системы репортинга и статистики.

позволяет абстрагировать доступ к данным достаточно серьёзно.

Только не абстрагировать, а разграничить.
Абстракции не предлагает никакой сервер, даже Оракл.

в любую ERP-систему корпоративного уровня. Но ратовать за повсеместное использование ORM и вздымать знамя до небес я б не стал.

Сравнивать ЕРП  с ОРМ это как сравнивать министерство промышленности с обувной мастерской

у неё просто есть своя ниша.

Я бы даже сказал не ниша, а малюсенькая точечная задачка - персистинг библиотеки кодовых объектов.

[Paramedic]

Не уведет. У него нет на этом уровне доступа к БД, в отличии от скл-программера.

Вот тебе простой пример.

SELECT * FROM SaveProcedure(125, 45, 89);

На выходе имеем DataSet. Где у SQL программера доступ к БД? У тебя какое-то недопонимание привилегий и ролей в РСУБД.