Замена невидимых компонентов с кодом

"Заменяет невидимые компоненты кодом" доказанный метод оптимизации в Delphi 7. Главным образом относительно Доступа к базе данных.

6
задан Vinayak Mahadevan 14 June 2010 в 13:14
поделиться

4 ответа

Обычно нет. Использование невизуальных компонентов не требует дополнительных затрат. Он создается очень быстро и работает во время выполнения с той же скоростью, что и «созданный в коде».

0
ответ дан 8 December 2019 в 17:18
поделиться

На сайте, который вы цитируете, говорится о замене компонента dialog-box кодом, который отображает диалоговое окно без использования какого-либо компонента. Альтернатива - написать пару строк кода для установки и отображения диалогового окна всякий раз, когда оно вам нужно, и вообще отказаться от компонента. Однако это не совсем оптимизация по скорости или размеру. Это не оптимизация скорости, поскольку ваш код все равно будет делать то же самое, что делал бы компонент, и это не оптимизация размера, поскольку место, занимаемое одним компонентом в программе, ничтожно мало.

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

9
ответ дан 8 December 2019 в 17:18
поделиться

Я не понимаю, как набор данных / запрос / таблица на основе формы будет быстрее или медленнее, чем созданный в коде. Однако мне нравится вставлять их в код, так как их легче поддерживать. Я видел экраны со встроенным SQL в компонент, а затем его переопределением в коде. Затем я должен остановиться и исследовать, чтобы определить, какой SQL на самом деле действует. Иногда SQL в форме хорош, иногда он используется какое-то время, а затем игнорируется кодом, иногда он никогда не активен, и SQL игнорируется в formcreate. Поэтому я должен определить, было ли это намеренно или просто небрежные остатки. Кроме того, легко пропустить изменения SQL при проверке кода, если они находятся в .DFM, а не в .PAS. то есть я не всегда смотрю на .DFM, потому что меня не интересует, изменилась ли подпись метки или переместилась кнопка.

Так что, хотя это хорошо для прототипирования, когда дело касается производственного кода, вам лучше иметь всю логику вашей базы данных (SQL, определения таблиц и полей) в файле .pas.

Обновление: наконец-то я попробовал CnPack . Среди десятков полезных свойств есть блестящий инструмент под названием «преобразование выбранных компонентов в код». Мастер дизайна форм | Подробнее ... | Преобразование выбранных компонентов в код. Он все делает за вас.

4
ответ дан 8 December 2019 в 17:18
поделиться

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

Кстати, оптимизация - это не про "проверенные методы" - это про определение проблемы и ее решение. Если проблема заключается в медленном доступе к БД, то это то, что вы должны изменить.

1
ответ дан 8 December 2019 в 17:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: