куча query,table и т.д.

← →
zdm © (2006-08-10 10:11) [0]

Всем привет, как Вы думаете, что лучше взять один компонент(ну допустим query или table) и во всем коде проги пытатсься работать только с ним(что в принципе можно ,,, не считая ситуаций если какие-то компоненты отображения инфы БД явно подвязаны), или лучше не напрягаться , и на каждую таблицу или процедуру, функцию, вьювер,,,создать отдельные компоненты, привязать их к элементам отображения и жить спокойно(понятное дело ОЗУ очень ценная вещь), но насколько это рентабильно.....?

← →
Ega23 © (2006-08-10 10:14) [1]

На каждый dbcontrol - свой dataset. Если память хочешь экономить - грамотно открывай их и закрывай.

← →
ANB © (2006-08-10 10:19) [2]

> На каждый dbcontrol - свой dataset.

И на каждый DBEdit тоже ?

Автору - дело вкуса. Я обычно то, что будет отображаться цепляю на статические (дизайн-таймовые) компоненты, особо частые вызовы процедур и DML - тоже на статические. Где нибудь внутрях, в сервисных функциях создаю динамически. Если используется многопоточность - то только динамически.

← →
Ega23 © (2006-08-10 10:25) [3]

> И на каждый DBEdit тоже ?

Нет, конечно. Правда я их никогда и не использую.

← →
zdm © (2006-08-10 10:25) [4]

ну в целом таких ответов я и ожидал,,,,вообщем подводя итог если есть возможность ---->не цепляй лишние компоненты а если напряжно или лень ,,,(вспомнил шутку ,,,когда нельзя но очень хочеться ,,,то можно) цепляй,,,,Ладно , Всем большое спасибо

← →
ANB © (2006-08-10 10:27) [5]

> если есть возможность ---->не цепляй лишние компоненты

Таки то что вяжется к отображению - лучше статически завести компоненты. Причем удобнее будет сразу заполнить их полями и все настроить. В противном случае будет слишком много непроизводительного кода.

← →
Ega23 © (2006-08-10 10:29) [6]

> Таки то что вяжется к отображению - лучше статически завести
> компоненты. Причем удобнее будет сразу заполнить их полями
> и все настроить. В противном случае будет слишком много
> непроизводительного кода.

Поддерживаю. Дополню: и держать их в DataMudule.

← →
Slym © (2006-08-10 10:31) [7]

В многооконном проекте лучше все создавать динамически (on demand)
окошки в первую очередь и db компоненты кидат на формы не используя центрального датамодуля. центральный датамодуль использовать как контейнер конекшина и регулярной бизнес логики

← →
Neo Trinitron © (2006-08-10 10:52) [8]

У меня для каждого запроса возвращающего данные свой статический TQuery, но чаще всего ещё есть один-два TQuery для выполнения динамических запросов. Моя практика показала что это удобно. Для статических запросов настраиваются поля и прочие настройки, что весьма удобно, для динамического запроса ничего кроме соединения не настраиваю - там полная свобода действий. Компактно, удобно, универсально. ИМХО.

← →
Ega23 © (2006-08-10 11:01) [9]

> У меня для каждого запроса возвращающего данные свой статический
> TQuery, но чаще всего ещё есть один-два TQuery для выполнения
> динамических запросов. Моя практика показала что это удобно.
> Для статических запросов настраиваются поля и прочие настройки,
> что весьма удобно, для динамического запроса ничего кроме
> соединения не настраиваю - там полная свобода действий.
> Компактно, удобно, универсально. ИМХО.

Вот и у меня также. За исключением того, что динамический dataset - строго один.

← →
Slym © (2006-08-10 11:18) [10]

Neo Trinitron © (10.08.06 10:52) [8]
для динамического запроса
Динамически и создавай Query...

← →
Ega23 © (2006-08-10 11:30) [11]

> Динамически и создавай Query...
>

Зачем? Каждый раз создавать, настраивать коннект, убивать...
Создал в дата модуле один раз и все...

← →
MsGuns © (2006-08-10 15:33) [12]

Для каждого отображаемого датасета - свой "дизайнерский" компонент доступа, для апдэйтов - единый и настраиваемый.
Реализация событий датасетов, сервиса (поиски, сортировки и т.д.) по максимуму в датамодуле.

← →
Neo Trinitron © (2006-08-10 15:51) [13]

> Вот и у меня также. За исключением того, что динамический dataset - строго один.

У меня очень редко встречаются ситуации когда нужно парочку Query для решения задач. Скажем так, ситуация когда используется сразу два динамических запроса одновременно.

>Динамически и создавай Query...

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

← →
Ega23 © (2006-08-10 16:13) [14]

> считаю динамически создавать такой объект неправильной технической
> мыслью...
>

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

← →
evvcom © (2006-08-10 16:16) [15]

> [6] Ega23 © (10.08.06 10:29)
> Дополню: и держать их в DataMudule.

Все зависит от задачи. Наш проект содержит уже чуть ли не сотню форм, часть из них строится динамически на базе шаблона. Формы стараемся не перегружать, потому зачастую достаточно одной пары DataSet-DataSource. Прикинь, все ЭТО выложить в один DataModule (далее DM)! Причем может существовать несколько экземпляров одного класса формы. И как это разруливать с одним DM? Создавать на каждую форму еще и DM? Или все же пару DS-DS положить на форму?.. Вот и я о том же.
> [12] MsGuns © (10.08.06 15:33)
> для апдэйтов - единый и настраиваемый

Даже для TUpdateSQL и ему подобных? Не согласен.

← →
evvcom © (2006-08-10 16:20) [16]

Кстати, ненавижу в тексте типа:
SQL.Clear; SQL.Add("select ..."); SQL.Add("from ..."); SQL.Add("where ..."); SQL.Add("order by ..."); SQL.Execute;
Мое имхо, лучше это в designtime написать. И понятнее, и нагляднее.

← →
Ega23 © (2006-08-10 16:49) [17]

> SQL.Execute;

Ну если Select, то лучше Open....

> Наш проект содержит уже чуть ли не сотню форм, часть из
> них строится динамически на базе шаблона.

Обычно делаю так: есть главная форма, как правило на ней PageControl с несколькими страницами ну и гриды с прочим DBAware.
Вот для этого - DataModule.
Для всех модальных настроечных форм, которые в процессе создаются-убиваются, все DataSet-DataSource лежат на самой модальной форме.
Базовые запросы почти всегда открыты. Остальные - открываются по мере надобности.

← →
evvcom © (2006-08-10 16:55) [18]

> Ну если Select, то лучше Open....

Ну да. Точно.

> Обычно делаю так

Ну другое дело. :)

← →
Neo Trinitron © (2006-08-10 18:52) [19]

А я все датасеты храню строго в датамодулях. Программа состоит из подсистем, состоящих из совокупности форм. Для каждой подсистемы свой датамодуль. Есть один главный датамодуль содержащий коннект, динамический Query и всё общее для всех остальных датамодулей, остальные датамодули юзают главный. Делаю так уже года два - доволен как слон. А выкладывать на формы - жуть! Всё познаётся в сравнении...

Преимущества:

1. Мне пофиг 100, 200 или 300 форм - наращивание делается так же просто как и при полном отсутствии функционала.
2. См.1, то же касается и поддержки.
2. Всё выглядит до тошноты однообразно, просто, не путается под ногами.
3. Грамотное открытие и закрытие датасетов - лёгкая задача.

← →
SergP. (2006-08-10 19:35) [20]

> [16] evvcom © (10.08.06 16:20)
> Кстати, ненавижу в тексте типа:
> SQL.Clear;
> SQL.Add("select ...");
> SQL.Add("from ...");
> SQL.Add("where ...");
> SQL.Add("order by ...");
> SQL.Execute;
> Мое имхо, лучше это в designtime написать. И понятнее, и
> нагляднее.

Мне больше нравится:
SQL.text:="select ... from ... where ...";
Open;

к тому же где-то читал о возможных глюках при использовании варианта [16] при работе с некоторыми базами...

← →
evvcom © (2006-08-11 09:29) [21]

> [19] Neo Trinitron © (10.08.06 18:52)

А про недостатки чего молчишь?
Недостатки:
1. Невозможно создать более одной формы конкретного класса.
2. В случае большой (и не очень) подсистемы на датамодуле визуально очень тяжело найти нужный датасет.
3. Для просмотра SQL (имени процедуры) датасета необходимо переключаться на датамодуль, который в свою очередь тоже еще нужно найти. (Актуально до версий D7, может D6. D6 практически не пользовал, не помню разворачиваются ли в инспекторе объектов свойства других объектов в виде дерева)

Может еще чего забыл...

← →
Sergey13 © (2006-08-11 09:38) [22]

> [21] evvcom © (11.08.06 09:29)

Большие и сложные проекты вообще труднее писАть, чем маленькие и простые. (из личного опыта)
8-)

← →
Neo Trinitron © (2006-08-11 10:15) [23]

evvcom,

1. Совершенно не понял что такое форма конкретного класса...
2. Поскольку для каждой подсистемы свой датамодуль, то датасетов на нём не так уж и много и каждый из них кстати подписан. Ещё скажи что на обычной форме один датасет чем-то визуально отличается от другого...
3. Трудно найти? Странно! Мне легко! Открываю нужную форму, смотрю Uses, там находится обычно модуль типа UDM... Это и есть датамодуль, Ctrl+клик мышей по этому модулю и нужный датамодуль открыт. Что тут сложного? Уровень дрессированной обезьяны. :) Кроме того, куча неинтересного кода работающего с базой реализовано в датамодуле, что даёт вполне понятные преимущества, скрывая его от разработчика.

Могу с полной уверенностью сказать что от этой методы не отойду ни за что. За 10 лет мытарств дошёл до этого, чему очень рад. Попробуйте так, не пожалеете.

← →
Lexiy (2006-08-11 12:14) [24]

ммм помогите не просвещеному все понял кроме понятия дата модуль ... что за зверь ... а то интересно .... по вашим рассуждениям очень красивая штука выходит :)

← →
Lexiy (2006-08-11 12:16) [25]

кстати хочется добавить к 16 ... вариант рисовки запросов в Query чреват долгим поиском его по форме ... сам не любил пока их в программе не стало больше 30 :)

← →
evvcom © (2006-08-11 12:54) [26]

> [23] Neo Trinitron © (11.08.06 10:15)
> 1. Совершенно не понял что такое форма конкретного класса...

Очень странно, учитывая 10 летний стаж. Например, создаем форму-справочник TMyForm, которая связана с датасетом на датамодуле. Открываем в приложении этот справочник: TMyForm.Create(Application).Show;. Создаем какую-то 2-ую форму TForm2, которая использует справочник класса TMyForm, но используя дополнительно какой-то фильтр данных. Каково будет решение? Создать еще один объект этого конкретного класса TMyForm, наложив нужные фильтры или использовать уже созданный объект-форму, испортив своими фильтрами прежний вид формы? И что в этом случае делать с НД?
2. Подсистемы разные бывают...
3. Заметь есть разница между "трудно найти" и "еще нужно найти". Кроме того, я упомянул про D7, где переключаться для этого вовсе необязательно.

> смотрю Uses
> Ctrl+клик мышей

+ клик на датасете

> Что тут сложного? Уровень дрессированной обезьяны

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

> Попробуйте так, не пожалеете.

Пробовал когда-то. Кажется во 2-ой или 3-ей версии они появились. Но даже 10-15 пар dataset-datasource на одном датамодуле меня раздражали сложностью визуального поиска нужного компонента. Сейчас у меня есть один датамодуль, на котором лежат DBSession, ConnectDialog, ImageList и 4 общих глобальных датасета. Все.

> [24] Lexiy (11.08.06 12:14)
> помогите не просвещеному все понял кроме понятия дата модуль
> ... что за зверь

Файл - New - Data Module

← →
Lexiy (2006-08-11 13:13) [27]

evvcom
а материалы по работе ??? или в примерах поискать ?

← →
Lexiy (2006-08-11 13:15) [28]

ммм ... грубо говоря такая байда куда можно свалить все компоненты что бы не мешались на формах ??? я правильно понял ??? .... а доступ в юнитах как реализуется стандартно или нет ???

> [28] Lexiy (11.08.06 13:15)
> грубо говоря такая байда куда можно

правильно

> а доступ в юнитах

стандартно через объект-наследник от TDataModule

← →
Lexiy (2006-08-11 13:47) [30]

угу понял ... спасибо :)

evvcom,

Это Ваш стиль программирования, а то мой, спорить имхо глупо.

>Вот обезьянью
>работу я и пытаюсь избегать по возможности

А я наоборот пытаюсь всю работу разложить на такие простые кусочки чтобы даже дресированная обезъяна могла разобрать мои каракули. Не буду спорить, программируйте как Вам нравится, а новички пускай попробуют так и так и выбирут что им ближе.

По поводу форм. Кто Вам мешает создать динамически второй датамодуль для второй формы? Или я не понимаю о чём речь...

>
> По поводу форм. Кто Вам мешает создать динамически второй
> датамодуль для второй формы? Или я не понимаю о чём речь.
> ..
>

Речь о повторном использовании кода.

> Кто Вам мешает создать динамически второй датамодуль для
> второй формы?

А в коде формы ты к датамодулю как обращаешься?

>А в коде формы ты к датамодулю как обращаешься?

Можно сделать типа этого: в форме локальная переменная

MyDataModule: TMyDataModule;
...

procedure TForm1.Create...;
begin
MyDataModule: TMyDataModule.Create...
...
end;

Не лучший вариант, многое зависит от задач и способов реализации. Я, например, с такой ситуацией не сталкивался, но если прийдётся, не проблема.

Вопрос: а нахрена создавать дата-модуль, если можно на форму положить???

Я обычно делаю так - статику в дата-модуль. Динамику - на форму или вообще в воздухе оставляю (главное - не забыть грохнуть).
Если сама форма динамическая, то проще на нее все и покидать. Хотя все равно придется вязать к статической сессии в дата-модуле.

> Я, например, с такой ситуацией не сталкивался

За 10 лет ни разу? Интересно, что ж ваш отдел (группа) пишет, "Hello World"?

> [35] Ega23 © (11.08.06 17:13)

И я о том же... Все, ушел...

Ega23,

>а нахрена создавать дата-модуль, если можно на форму положить???

Если до сих пор не понадобилось, то уже и не понадобится...

evvcom,

>За 10 лет ни разу? Интересно, что ж ваш отдел (группа) пишет, "Hello World"?

Очевидно не то что пишете Вы, но это не значит что я пишу "Hello Word". Если такой умный и опытный, зачем делать такие глупые предположения? Попытка рассказать что у меня дурацкий стиль программирования? А ещё не терпите обезъянью работу, но похоже обезъяньи развлечения рулят, я угадал?

Я тоже мог бы рассказывать что кидать на форму датасеты, обработчики событий датасетов и прочий прилегающий код - дилетанство, потому что мне так не удобно, но я же не делаю так! Зато приходилось разгребать код где на формах валяются датасетов куча. Вынес всё в датамодули, стало реально видно логику самой формы. В модуле формы стало кода всего на три экрана, до модернизации было 7 (!) экранов. Извините, но меня никто не переубедит что так как Вы предлагаете удобнее. Я датамодули строю по принципу классов: выделяю общности, включаю датамодули с общностями в датамодули реализации отдельной подсистемы. Кажется что всё сложно, на самом деле к датамодулям общим я практически никогда не обращаюсь при разработке: один раз сделал там всё и открываю редко, по мере необходимости, а к датамодулям подсистем я обращаюсь чаще, но там отсутствует куча датасетов, которые являются общими и которые меня мало интересуют. Это же обыкновенный принцип ООП... Не понятны затруднения...

> В модуле формы стало кода всего на три экрана, до модернизации
> было 7 (!) экранов.

И что? У меня модуль главной формы на 8000 строк кода. Там на 3 экрана только описание компонентов. И ничё, нормально работает.

> И что? У меня модуль главной формы на 8000 строк кода. Там на 3 экрана только описание компонентов. И ничё, нормально работает.

Вот прийдёт новичёк, посадишь его за машину и пущай изучает проэкт, можно засекать время...А если там ещё и датасеты есть, то вообще полный алес среди этой шелухи. Имхо 8000 строк кода в одной форме - ненормальный случай. У меня была такая форма, всё что мог вынес в отдельный модуль в виде процедур, функций, объектов, чтобы под ногами не путалось. Датасеты и всю их начинку, естественно в датамодуль...Остались в модуле формы те же преславутые три-четыре экрана. И когда я уходил с работы я обучал парнишу, обучение заняло 30 минут. Описание всех функций и процедур успешно он изучил сам и систему понял довольно таки быстро...Результаты, однако.

куча query,table и т.д. Найти похожие ветки