| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
куча query,table и т.д.
zdm © (2006-08-10 10:11:00)Всем привет, как Вы думаете, что лучше взять один компонент(ну допустим query или table) и во всем коде проги пытатсься работать только с ним(что в принципе можно ,,, не считая ситуаций если какие-то компоненты отображения инфы БД явно подвязаны), или лучше не напрягаться , и на каждую таблицу или процедуру, функцию, вьювер,,,создать отдельные компоненты, привязать их к элементам отображения и жить спокойно(понятное дело ОЗУ очень ценная вещь), но насколько это рентабильно.....?
evvcom (2006-08-11 09:29:00) [21]> [19] Neo Trinitron © (10.08.06 18:52)
А про недостатки чего молчишь?
Недостатки:
1. Невозможно создать более одной формы конкретного класса.
2. В случае большой (и не очень) подсистемы на датамодуле визуально очень тяжело найти нужный датасет.
3. Для просмотра SQL (имени процедуры) датасета необходимо переключаться на датамодуль, который в свою очередь тоже еще нужно найти. (Актуально до версий D7, может D6. D6 практически не пользовал, не помню разворачиваются ли в инспекторе объектов свойства других объектов в виде дерева)
Может еще чего забыл...
SergP. (2006-08-10 19:35:00) [22]> [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] при работе с некоторыми базами...
Neo Trinitron (2006-08-10 18:52:00) [23]А я все датасеты храню строго в датамодулях. Программа состоит из подсистем, состоящих из совокупности форм. Для каждой подсистемы свой датамодуль. Есть один главный датамодуль содержащий коннект, динамический Query и всё общее для всех остальных датамодулей, остальные датамодули юзают главный. Делаю так уже года два - доволен как слон. А выкладывать на формы - жуть! Всё познаётся в сравнении...
Преимущества:
1. Мне пофиг 100, 200 или 300 форм - наращивание делается так же просто как и при полном отсутствии функционала.
2. См.1, то же касается и поддержки.
2. Всё выглядит до тошноты однообразно, просто, не путается под ногами.
3. Грамотное открытие и закрытие датасетов - лёгкая задача.
evvcom (2006-08-10 16:55:00) [24]> Ну если Select, то лучше Open....
Ну да. Точно.
> Обычно делаю так
Ну другое дело. :)
Ega23 (2006-08-10 16:49:00) [25]
> SQL.Execute;
Ну если Select, то лучше Open....
> Наш проект содержит уже чуть ли не сотню форм, часть из
> них строится динамически на базе шаблона.
Обычно делаю так: есть главная форма, как правило на ней PageControl с несколькими страницами ну и гриды с прочим DBAware.
Вот для этого - DataModule.
Для всех модальных настроечных форм, которые в процессе создаются-убиваются, все DataSet-DataSource лежат на самой модальной форме.
Базовые запросы почти всегда открыты. Остальные - открываются по мере надобности.
evvcom (2006-08-10 16:20:00) [26]Кстати, ненавижу в тексте типа:
SQL.Clear;
SQL.Add('select ...');
SQL.Add('from ...');
SQL.Add('where ...');
SQL.Add('order by ...');
SQL.Execute;
Мое имхо, лучше это в designtime написать. И понятнее, и нагляднее.
evvcom (2006-08-10 16:16:00) [27]
> [6] Ega23 © (10.08.06 10:29)
> Дополню: и держать их в DataMudule.
Все зависит от задачи. Наш проект содержит уже чуть ли не сотню форм, часть из них строится динамически на базе шаблона. Формы стараемся не перегружать, потому зачастую достаточно одной пары DataSet-DataSource. Прикинь, все ЭТО выложить в один DataModule (далее DM)! Причем может существовать несколько экземпляров одного класса формы. И как это разруливать с одним DM? Создавать на каждую форму еще и DM? Или все же пару DS-DS положить на форму?.. Вот и я о том же.
> [12] MsGuns © (10.08.06 15:33)
> для апдэйтов - единый и настраиваемый
Даже для TUpdateSQL и ему подобных? Не согласен.
Ega23 (2006-08-10 16:13:00) [28]
> считаю динамически создавать такой объект неправильной технической
> мыслью...
>
Ничего неправильного в мысли нет, просто с однажды созданным - удобнее.
Это всё равно что ADOConnectionкаждый раз создавать для каждого запроса.
В принципе - можно. Нафига - непонятно.
Neo Trinitron (2006-08-10 15:51:00) [29]> Вот и у меня также. За исключением того, что динамический dataset - строго один.
У меня очень редко встречаются ситуации когда нужно парочку Query для решения задач. Скажем так, ситуация когда используется сразу два динамических запроса одновременно.
>Динамически и создавай Query...
Я не думаю что один раз созданный TQuery затянет больше ресурсов чем каждый раз создавать и удалять объект, кроме того читабельность кода страдает, считаю динамически создавать такой объект неправильной технической мыслью...
MsGuns (2006-08-10 15:33:00) [30]Для каждого отображаемого датасета - свой "дизайнерский" компонент доступа, для апдэйтов - единый и настраиваемый.
Реализация событий датасетов, сервиса (поиски, сортировки и т.д.) по максимуму в датамодуле.
Ega23 (2006-08-10 11:30:00) [31]
> Динамически и создавай Query...
>
Зачем? Каждый раз создавать, настраивать коннект, убивать...
Создал в дата модуле один раз и все...
Slym (2006-08-10 11:18:00) [32]Neo Trinitron © (10.08.06 10:52) [8]
для динамического запроса
Динамически и создавай Query...
Ega23 (2006-08-10 11:01:00) [33]
> У меня для каждого запроса возвращающего данные свой статический
> TQuery, но чаще всего ещё есть один-два TQuery для выполнения
> динамических запросов. Моя практика показала что это удобно.
> Для статических запросов настраиваются поля и прочие настройки,
> что весьма удобно, для динамического запроса ничего кроме
> соединения не настраиваю - там полная свобода действий.
> Компактно, удобно, универсально. ИМХО.
Вот и у меня также. За исключением того, что динамический dataset - строго один.
Neo Trinitron (2006-08-10 10:52:00) [34]У меня для каждого запроса возвращающего данные свой статический TQuery, но чаще всего ещё есть один-два TQuery для выполнения динамических запросов. Моя практика показала что это удобно. Для статических запросов настраиваются поля и прочие настройки, что весьма удобно, для динамического запроса ничего кроме соединения не настраиваю - там полная свобода действий. Компактно, удобно, универсально. ИМХО.
Slym (2006-08-10 10:31:00) [35]В многооконном проекте лучше все создавать динамически (on demand)
окошки в первую очередь и db компоненты кидат на формы не используя центрального датамодуля. центральный датамодуль использовать как контейнер конекшина и регулярной бизнес логики
Ega23 (2006-08-10 10:29:00) [36]
> Таки то что вяжется к отображению - лучше статически завести
> компоненты. Причем удобнее будет сразу заполнить их полями
> и все настроить. В противном случае будет слишком много
> непроизводительного кода.
Поддерживаю. Дополню: и держать их в DataMudule.
ANB (2006-08-10 10:27:00) [37]
> если есть возможность ---->не цепляй лишние компоненты
Таки то что вяжется к отображению - лучше статически завести компоненты. Причем удобнее будет сразу заполнить их полями и все настроить. В противном случае будет слишком много непроизводительного кода.
zdm (2006-08-10 10:25:00) [38]ну в целом таких ответов я и ожидал,,,,вообщем подводя итог если есть возможность ---->не цепляй лишние компоненты а если напряжно или лень ,,,(вспомнил шутку ,,,когда нельзя но очень хочеться ,,,то можно) цепляй,,,,Ладно , Всем большое спасибо
Ega23 (2006-08-10 10:25:00) [39]
> И на каждый DBEdit тоже ?
Нет, конечно. Правда я их никогда и не использую.
ANB (2006-08-10 10:19:00) [40]
> На каждый dbcontrol - свой dataset.
И на каждый DBEdit тоже ?
Автору - дело вкуса. Я обычно то, что будет отображаться цепляю на статические (дизайн-таймовые) компоненты, особо частые вызовы процедур и DML - тоже на статические. Где нибудь внутрях, в сервисных функциях создаю динамически. Если используется многопоточность - то только динамически.
| |
Страницы: 