Замена невизуальных компонентов кодом

Question

Является ли «Замена невизуальных компонентов кодом» проверенным методом оптимизации в Delphi 7. В основном в отношении доступа к базе данных.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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