VladiChВопрос для всех противников объектного слоя.
Как вы думаете, для чего существуют ORM-средства и кто ими пользуется?
Для тех кто не знает что это такое
Имхо все это реинкарнация идей про RAD. Вот я набросал мышкой метаданные(описал хмл-файлом, импортировал из розы итп)-и вот вам готовое приложение.
Для определенного класса задач это приемлемый подход.
Иногда довольно серьезные приложения пишутся на Ацессе с линкованными таблицами.
Никогда не сталкивались? :) Вот ОРМы, что-то в этом роде. До определенного уровня вполне приемлемо. Но только до него.

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


VladiChЧто вы называете оптимальным кодом и структурой? А вы дадите гарантию, что вы генерите такой код и структуру вручную? А доказать можете?
А кто-нибудь вообще может дать такую гарантию? Какие-то странные вопросы вы задаете.
Да, я считаю, что код генерится достаточно оптимальный для моей задачи. Вручную его можно конечно оптимизировать лучше, но возможности для ручной оптимизации в системе есть. А там, где такая оптимизация не нужна, я могу кучу времени сэкономить на разработке и поддержке.
Вы можете дать гарантию, что когда вам потребуется форсировать джойн-ордер или использование какого-нибудь индекса для конкретного тяжелого списка это:
а) будет вообще возможно
б) не затронет места, которые затрагивать не должно.
Вы можете дать подобные гарантии для случаев, когда запрос нужно переписать кардинально - с использованием юнионов или временных таблиц?
А для случаев, когда необходимо явное управлению уровнем изоляции\блокировками запросов?
Только не говорите, что вашему приложению это не грозит. Это много скажет о вашем приложении :)


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

VladiChПопробуйте например построить сложное приложение на чистом Pascal без использования ОО-расширений - поймете.
Ну за паскаль не скажу... Си подойдет?
Виндовз. Если у вас аллергия на виндоз - Юникс. :)

VladiChORM к RAD не имеет абсолютно никакого отношения.Я в курсе. Просто имхо это чем-то родственные идеи.
VladiCh DrKonitoДа, кстати ОРМы очень уязвимы к устареванию технологий и политике поставщика\настроению гениального программиста. Так, что если вам нужно не слишком сложное, малонагруженное приложение сроком службы 2-3 года, то вам с ними по пути.
Зависит от конкретного ORM. В общем случае согласен. Но я не использую сторонний ORM, мне своего достаточно.Тогда в роли гениального программиста выступаете вы и ваши коллеги и преемники зависят от вас. И еще, им тоже хочется написать _свой_ крутой суперпроизводительный обжект-релэшонал маппер ;).

VladiCh DrKonitoТ.е. вы начитываете "тяжелый список" из СУБД обычным sql-запросом, а потом на СП придумываете для этого списка какой-нибудь класс в вашей объектной модели?
Думаю у вас, по меньшей мере, большая объектная модель. Или я ошибаюсь?
Поясните, что вы понимаете под списками вообще и "тяжелыми списками" в частности.
Объектная модель пока небольшая - порядка сотни классов (я говорю разумеется только про те, которые описаны в БД).
Список=резалтсет, рекордсет, набор записей, датасет (выберите что вам ближе)
Под "тяжелым списком" я имею в виду запросы возвращающие сотни-тысячи-десятки тыщ записей, которые имеют достаточно сложную логику и медленно выполняются даже на чистом SQL.
VladiCh
DrKonito
VladiChПопробуйте например построить сложное приложение на чистом Pascal без использования ОО-расширений - поймете.
Ну за паскаль не скажу... Си подойдет?
Виндовз. Если у вас аллергия на виндоз - Юникс. :)
Ну давайте еще PL/1 и OS/360 вспомним... Конечно на этих языках писался большой софт. И сколько человек было в этих проектах задействовано?
Помню, когда ООП была новой темой были модны опыты на чем быстрее писать на Си или ЦПП. Группа программистов написал растровый редактор на Си, а потом переписала его на ЦПП.
Никакой разницы в скорости разработки выявлено не было :) Ссылку сейчас дать затруднительно - это год 1995 кажется был, журнал то-ли МирПК, толи еще что-то в этом духе.
Скажете-такие программисты :) А программисты они везде примерно одинаковые, а в ай-ти отделах особенно :)
А вы Брукса читали про то что нет "серебрянных пуль"? Или может хотя бы Джоела Спольски (который ДжоелОнСофтваре)? Имхо скорость разработки зависит от людей и задачи и меньше всего от инструмента. Если не брать конечно крайности.

Всем защитникам обязательной объектной ориентированности.

Имхо чтобы необходимость технологии представляющей новый уровень абстракции над "процедурным SQL", действительно была несомненна, а не приводила к пустому флэйму на форумах, она действительно должна означать повышение производительности труда, как минимум на порядок, по сравнению с "покрываемой" им низкоуровневой технологией
Как Си над асм-ом, как SQL над самостоятельным оперированием хэш-джойнами, как VB над Си в области интерфейса.
Не меньше. Иначе будут невразумительные заявления "А мне так удобнее - все заткнитесь". "А это сам Фаулер сказал - как вы не знаете кто такой Фаулер?". "А у Буча так написано - Всем читать Буча три раза".

И еще это должна быть зрелая технология. Не самопальная вечно недописанная обертка, не очередная продукция отдела маркетинга БольшойФирмы, а технология у которой есть хотя-бы десятилетняя перспектива.

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