Ответ на »сообщение 349« (Сергей Перовский)
___________________________

А оно надо? Очень надо? Тогда расскажите, зачем.
Не понял. Вы же сами говорили, что проектировать надо на ООП, а не в реляционной БД. ORM и дает эту возможность.

Мне никак не удается понять. Все примеры, которые приводят сторонники ORM мне кажутся надумаными - в них объектная и реляционнная модель спроектированы по разным принципам и возникает искусственная задача описания соответствия.
Сергей, когда я использую ORM я НЕ проектирую реляционную модель. Это не моя проблема. Мне достаточно описать задачу в терминах ООП.
Можно ли все делать без ORM? Безусловно. Но приходится руками писать кучу кода, который по идее уже написан разработчиками ORM.

Ответ на »сообщение 345« (Geo)
___________________________

Почему я должен для этого создавать ClientDataSet, выгружая в него данные из таблицы?
Потому что.
Недавно в одной книге я прочитал фразу: "Прежде чем нарушать правило, необходимо его как следует выучить".
Вы, Юрий, выучили правила работы с БД в Delphi, поэтому Вам можно нарушать. Но того, кто не выучил, лучше бить по рукам. По крайней мере, это намного проще, чем долго и вдумчиво учить его делать хорошие решения без db-aware.

Ответ на »сообщение 343« (panda)
___________________________
Но что делать, если CodeGear не предоставляет механизма ORM/OP?
А оно надо? Очень надо? Тогда расскажите, зачем.
Мне никак не удается понять. Все примеры, которые приводят сторонники ORM мне кажутся надумаными - в них объектная и реляционнная модель спроектированы по разным принципам и возникает искусственная задача описания соответствия.

Ответ на »сообщение 347« (Geo)
___________________________
Но случаи бывают разные. Бывают несчастные случаи :o) но к счастью сравнительно редко.

Ответ на »сообщение 346« (Cepгей Poщин)
___________________________
>>> Наверняка есть таблица с именами кого-нибудь, эту таблицу надо както отображать для выбора строки, для этого используется некоторый набор данных
Типовая ситуация -- это отображение в гриде данных из ReadOnly запроса. Наверное, в этом случае удобнее будет пользоваться механизмами, типа UpdateSQL, встроенными в компонент Query. Но случаи бывают разные.

Ответ на »сообщение 345« (Geo)
___________________________
Вот это вот ID=12 откуда взялось? Это что какаято глобальная настройка, которая всего одна?
Наверняка есть таблица с именами кого-нибудь, эту таблицу надо както отображать для выбора строки, для этого используется некоторый набор данных, потомок TDataSet (не обязательно TClientDataSet, это вопрос личных предпочтений). Так вот мой опус призывает к тому, что надо нормально его настроить и сделать редактируемым и привесить db-подобные компоненты, а не пытаться создать им самопальную замену. На создание полноценного аналога уйдёт слишком много времени, кроме того это будет источником ошибок как сейчас, так и в будущем.

Я вчера писал сообщение уже на бегу и, видимо, оно получилось не совсем удачным. Поясняю мысль...

Пусть я хочу послать серверу запрос

UPDATE MyTable SET Name='Вася' WHERE ID=12

Почему я должен для этого создавать ClientDataSet, выгружая в него данные из таблицы? Для того, чтобы DBAware-компоненты работали?!

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

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

Ответ на »сообщение 341« (Geo)
___________________________
Если мне нужно работать с одной единственной записью и разнести поля этой записи по форме, то этого нет. Одна — частный случай 10, не вижу проблем. А если Вас попросят добавить к редактору одной строки в виде формы еще и редактор того же, но в виде таблицы, ну привык пользователь к Excel. То, что на первый взгляд кажется долго создавать DataSet, поля и т.п., так потребуется для своих редакторов фильтровать буквы, контролировать максимальную длину поля, да мало ли что и если ни чего не забыть, то времени потребуется еще больше.

В общем я не утверждаю, что сделать лучше чем есть невозможно, но сколько не приходилось править программ (включая и свои) за 10 лет, ни где не встречал такого.

Ответ на »сообщение 341« (Geo)
___________________________

Авторы Delphi не сделали механизма, который бы позволял по введенным в Edit'ы значениям формировать и отправлять на сервер запрос UPDATE. Вернее, сделали, но только один единственный -- грид. Если мне нужно работать с одной единственной записью и разнести поля этой записи по форме, то этого нет.
А вот с этого места, пожалуйста, поподробнее. С каких это пор логика работы разных db-aware контролов с DataSource стала отличаться? Вот только что посмотрел - TDBLookupComboBox работает ничуть не хуже, чем TDBGrid.

Вообще говоря, соглашусь с тем, что традиционный db-aware из Delphi 1 в современных условиях уже не является самым лучшим подходам. Но что делать, если CodeGear не предоставляет механизма ORM/OP? Искать сторонний? Ну... да, есть такие, только до нормальных аналогов из других платформ (таких как Hibernate или Spring) они, мягко говоря, не доросли. Разрабатывать свой - можно конечно. Но тогда встанет вопрос, а зачем делать что-то еще? Проще заняться исключительно бизнесом по разработке нормального ORM для Delphi.

DBEdit