Использование Delphi data-aware components-плюсы и минусы [закрыто]

попробовав как data-aware, так и non-data-aware стиль приложений Delphi, я вернулся в лагерь компонентов с данными в эти дни. Для правильного слоя кода требуется немного работы и дисциплины, но это все равно быстрее, чем делать все вручную, используя элементы управления без данных.

несколько моих советов по использованию компонентов с учетом данных:

• не просто переписать FishFact в большем масштабе. Вложи немного мыслей в свои дизайн.

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

• TDatasets принадлежат TDataModules, в то время как TDataSources принадлежат TForms (если не используется для отношений master/detail).

• используйте наборы данных в памяти, такие как DataSnap TClientDataSet.

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

  • соединения двух или более таблиц в один редактируемый набор данных

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

  • создавать только поля в памяти (например, вычисляемые поля, но вы можете писать в них также)

• вложенные таблицы TClientDataSet полезны, но не единственный способ выразить отношения основных деталей. Иногда лучше сделать это по-старому с двумя независимыми TClientDataSets, соединенными через TDataSource.

взгляните на решения ORM.

Это хороший подход с многоуровневой архитектурой. См.ORM для Delphi win32

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

Это не сложно, но вы должны знать, как вы можете это сделать.

один из подходов-иметь компоненты набора данных в DataModule (или другом не визуальном контейнере).

еще один удобный трюк-использовать TClientDataSet для записи пользовательского интерфейса и использовать его в качестве промежуточного буфера между пользовательским интерфейсом и бизнес-уровнем. Бизнес-слой затем использует компоненты TDataSet, специфичные для вашего слоя данных.

--jeroen

Delphi data-aware компоненты не зависят от серверного компонента database engine, который вы используете, поэтому использование Firebird или MS SQL Server или Oracle или других не имеет значения для ваших данных-aware компонентов. Они знают только компонент источника данных, назначенный им, и делают все свои связанные с БД вещи через это.

для меня, если что-то можно сделать с компонентами данных в хорошем смысле, я буду использовать их. Это, как правило, небольшие проекты, которые должны быть выполнены в короткие сроки. В большем проекты, я мог бы полностью исключить компоненты, учитывающие данные, или использовать их в формах, которые просто используются для представления данных и не получают ввода пользователя. Когда дело доходит до получения пользовательского ввода, я могу использовать компоненты, не связанные с данными, потому что у меня больше гибкости в управлении ими и проверке ввода. Конечно, компоненты data-ware также могут быть полезны в таких сценариях. Вы все еще можете проверить ввод данных Пользователем в событиях набора данных, таких как OnBeforePost. Также, если вы используете многоуровневый дизайн, и ваше клиентское приложение представляет уровень Data presenter, проверка ввода выполняется на среднем уровне, поэтому вы можете получать входные данные с помощью компонентов, поддерживающих данные в клиентском приложении, и отправлять их на средний уровень для проверки и дальнейшей обработки.

компоненты, учитывающие данные, полезны с точки зрения RAD и прототипирования, особенно когда вы разрабатываете отчеты или сетки, основанные на данных. т. е. вы можете возиться во время разработки. Поэтому я их так и использую. Но когда приходит время преобразовать его в код доставки, я почти всегда разрываю соединения, удаляю SQL из запросов и делаю все в коде. Это гораздо более предсказуемо и ремонтопригодно, особенно в среде нескольких разработчиков с контролем версий. Когда SQL встроен в форму где-то, это большая боль, чтобы попытаться выяснить, где SQL на самом деле находится. И особенно плохо иметь SQL в двух местах, а затем нужно выяснить, что в действительности.

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

в сочетании с Remobject SDK у вас будет хорошая комбинация из N-уровневой архитектуры и абстракции базы данных.