Каковы преимущества использования элементов управления версией DB Aware вместо элементов управления без DB Aware в Delphi

Я бы убедил друга, что использование компонентов базы данных (DB Aware Controls) в Delphi на сегодняшний день является лучшим вариантом при разработке приложений баз данных.

Это обсуждалось с ним много лет назад: до сих пор он убежден, что использование простых элементов управления, таких как TEdit, TStringGrid и т.д., с набором методов getter и setter для их заполнения, является лучшим решением как с точки зрения гибкости, так и с точки зрения гибкости и ремонтопригодность всего проекта.

Мне этот звук кажется интуитивно понятным.

Я думаю, что использование DB Aware Controls, таких как TDBEdit, TDBGrid и т.д., является правильным решением при разработке приложений баз данных.

Итак: пожалуйста, помогите мне убедить его со звуковыми советами об использовании элементов управления версией DB!

Благодарим вас заблаговременно всем, кто будет публиковать по крайней мере его собственный совет, независимо от того, что будет в пользу одного или другого решения.

- fabio vitale

Ответ 1

DB-Aware vs non-DB-Aware - это своего рода устаревшее обсуждение. Элементы управления DB-Aware имеют автоматическую привязку данных, что означает, что они автоматически обрабатывают данные, выполняют обнаружение изменений и записывают членам ограниченного источника данных; в элементах управления, отличных от dbaware, вам решать эти задачи. Это может также привести к запутанному коду - или к перестроенным фреймворкам просто для привязки данных. Оба сценария плохие.

Тип источника данных и качество отдельного элемента управления определяют производительность. Я видел много кода для databind TStringGrid просто для того, чтобы избежать TDBGrid из-за пуризма (когда TDbGrid будет делать красиво) - просто чрезмерно абсурдная потеря времени.

Это стало устаревшим обсуждением, когда TClientDataset стал де-факто набором данных для отключенных приложений: вы можете извлекать данные, отключать, работать с данными, снова подключаться и применять изменения. Поскольку элементы управления CDS + DbAware будут выполнять 99% интерфейса, вы используете элементы управления, не поддерживающие данные, для следующих 1% (для некоторых сложных интерфейсов).

У меня все еще нет XE2, чтобы увидеть, хорошо ли работает LiveBindings для работы с OO-данными. Если это так, теперь все элементы управления могут быть db-aware при необходимости.

РЕДАКТИРОВАТЬ: в да-мягком ответе он (она?) утверждает, что элементы управления DbAware реализуют шаблон MVC, а LachlanG не согласен с тем, что даже он делает это сам код MVC. Я дам здесь $0,02 цента; -)

Я думаю, что использование отношения 1:1 в DataModule и Entity (как в ERD) - или DataModule и Form - вы можете получить приложение, в котором разделены обязанности:

form dfm → Макет и привязка к времени разработки (имеют только источники данных)
form *.pas → управляет интерфейсом и запрашивает модуль данных для данных (действует как контроллер).
Модуль данных → методы ответа на запросы форм для поиска данных и обновления данных

Обычно у меня есть разделенный модуль данных для подключения к базе данных, который передается через свойства форм/сущностей.

Ответ 2

Элементы управления с поддержкой DB:

Работа по загрузке данных в элемент управления и сохранение данных в наборе данных выполняется VCL. У вас меньше кода - действительно RAD.
Элементы управления DB + TDataSource + TDataSet реализует шаблон MVC. Это помогает отделить GUI и код доступа к данным.
Проверка кода, переформатирование, выполнение другой последующей обработки данных будут вызываться в четко определенные моменты с использованием обработчиков событий. Это помогает централизовать такой код и избегать путаницы с местами, где он должен быть размещен. И избегайте путаницы с моментами, когда это можно назвать.

Минусы:

Это не универсальный подход. Вы не можете привязать элемент управления, поддерживающий DB, к источнику данных, отличных от TDataSet. Эта проблема была решена с внедрением привязки данных в Delphi XE2.
Программирование, управляемое событиями, может быть запутанным для некоторых разработчиков. И требует знания TDataSource, TDataSet, событий и архитектуры TField и приводит к разногласиям с Pros (3). Ошибочный код, управляемый событиями, может быть кошмаром.

Ответ 3

Оба компонента, поддерживающие DB и не поддерживающие DB, имеют преимущества и недостатки, в зависимости от того, какое приложение вы разрабатываете.

Для приложений малого и среднего масштаба рекомендуется использовать компоненты, поддерживающие БД, если только не существуют конкретные требования или условия, в которых работают эти приложения. Например, простое приложение для ввода данных было бы легче разрабатывать и поддерживать с компонентами, поддерживающими БД. Даже приложения среднего и крупного масштаба, если они правильно разработаны и реализованы, будут иметь хорошую производительность с компонентами, поддерживающими БД.

Однако при разработке модульных приложений, особенно многоуровневых систем, компоненты, поддерживающие БД, могут отрицательно влиять на производительность приложений и удобство обслуживания. Это особенно заметно для приложений, которые обращаются к данным через Интернет. Основной причиной этого является то, что компоненты, поддерживающие БД, требуют постоянного подключения к базе данных, что может значительно увеличить сетевой трафик.

Использование компонентов, не поддерживающих DB, может быть более сложным, поскольку оно требует лучшего понимания лежащих в его основе механизмов, но в многопользовательских и распределенных многоуровневых средах оно масштабируется намного лучше, чем что-либо еще. Кроме того, вы можете (и должны) отделять уровень доступа к данным от уровня представления (UI), который позже позволит вам вносить изменения в одну подсистему (модуль, слой), не изменяя ничего.

Сегодня данные могут быть в любом месте и в большинстве случаев, когда они не хранятся на локальных компьютерах или в сетях. Использование компонентов, поддерживающих БД, для доступа к этим данным может иметь существенное негативное влияние на производительность приложений и баз данных. Есть некоторые уровни доступа к данным, которые улучшают это (UniDAC, AnyDac,...), поэтому использование компонентов с поддержкой DB может повысить производительность. Тем не менее компоненты, не поддерживающие DB, могут превзойти все.

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

Ответ 4

Это может быть перенос опыта Visual Basic. Насколько я помню, даже Microsoft заявила разработчикам, что не использует контрольные элементы управления БД в производственном коде.

У Delphi никогда не было этой проблемы, но, как говорили другие, это зависит от типа проекта, который вы строите, и возникают ли у вас проблемы с производительностью.

Ответ 5

Анекдот: управляющий DB-код однажды испортил нашу базу данных InterBase: чтобы указать "пустую" или "нулевую" дату, элемент управления датой TcxDBDateEdit (ExpressQuantumGrid) использует значение даты отрицательное, которое представляет буквально "01/00/0000".

Итак, когда пользователи очистили поле редактирования даты в форме ввода и отправили это значение в базу данных, записи стали нечитаемыми (инструкции SELECT не удались).