Обсуждаем ORM

[Paramedic]

ну оно не для этого... это уровень сетевой безопасности, а не безопасности бизнес-логики или уровня данных.Это ты у себя спрашиваешь?

Секундочку. А при чём здесь Бизнес-Логика, и ORM? Я что, не могу реализовать бизнес-логику через реляционный подход? Реализую, куда быстрее и проще.

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

Это даже не твой гараж.

так я и говорю - это мой ЕЖ

ORM это инструмент, который пытается получить данные реляционным способом

У тебя неполное представление о назначении ОРМ
Главная задача ОРМ - это проектирование уровня данных. Ну и ессно, как следствие, наличествует функция чтения-записи объектов уровня данных в субд.

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

Я что, не могу реализовать бизнес-логику через реляционный подход?

Не можешь.

Реализую, куда быстрее и проще.

Наивный... видимо не попадалось тебе не школьных задачек

[Paramedic]

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

Ложное утверждение. Во-первых БД тоже проектируется. Рисуются ER-диаграммы.

Далее, тебе не приходит в голову, что к одной и той же БД обращается сразу несколько клиентов? Ты говоришь, изменилась предметная область. Значит надо переписать клиента, затем перекроить СУБД, и после этого переписать все остальные клиенты.

Обалдеть гибкость.

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

[Paramedic]

Не можешь.

Например?

Наивный... видимо не попадалось тебе не школьных задачек

На личности не перескакиваем.

[Paramedic]

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

Можно конкретный пример? Где уровень данных, где бизнес-логика, где ORM.

[Paramedic]

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

Что такое объект бизнес-логики? Как можно сохранять объект в РСУБД?

[Paramedic]

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

Угу. Тогда им приходиться переплачивать за железо. А почему бы не использовать технологию PDO, как например в PHP? Почему ORM?

[Paramedic]

Оно не лишнее, оно замещающее.

Оно лишнее. Замещающее, это когда пропадает необходимость в SQL. SQL никуда не делся. Только вышел из под контроля, и живёт своей жизнью.

При использовании ОРМ отпадает необходимость в проектировании БД.

Мде. Там, где нет проектирования БД, там говнопроект.

[Paramedic]

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

Ну мы этот вопрос уже рассмотрели. Роли и привилегии. Разработчик не имеет доступа к БД и её метаданным. Он работает только с DataSet.

[Paramedic]

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

Я бы ещё напомнил про Constraint. Заполняем, и опа -- даже при криворуком кодере и муха не проскочит.

[Paramedic]

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

Годится.

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

Как мы уже выяснили -- нет. Роли и привилегии не позволят.

Опять же, давай возьмём одноуровневое приложение на ORM. Вот тут реально получаем полный доступ. Ибо без полного доступа ORM не функционален.

[Paramedic]

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

И при чём здесь ORM? Всё это реализуется без ORM, и даже без БД. Можно данные в файлах хранить.

[Paramedic]

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

Красиво написано. Но покажи мне хоть одну ORM, где существует деление на роли и привилегии? Всё, что ты описал, делается средствами РСУБД. И опять же к ORM отношения не имеет.

[Paramedic]

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

Лукавый приём. Почему рассматривается одноуровневое SQL - приложение  и многоуровневое ORM? Давай лучше рассмотрим одноуровневое приложение на ORM и многоуровневое на SQL.