Использование компонентов, поддерживающих данные Delphi - плюсы и минусы

Ответ 1

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

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

Все различные биты кода события (и их взаимодействия) могут стать настоящим кошмаром, чтобы понять!

Неизменно в таких случаях я удалил компоненты, ориентированные на данные, и переключился на (ручной) проект MVC.

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

Ответ 2

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

Некоторые из моих советов по использованию компонентов с поддержкой данных

• Не переписывайте FishFact в большем масштабе. Подумайте о своем дизайне.

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

- Йерун

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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