Использование компонентов Delphi -Aware - Pros и Cons [закрыто

StackOverflow https://stackoverflow.com/questions/4722563

Вопрос

Я хочу знать ваше мнение об использовании компонентов с учетом данных в проектах. Каковы «силу» и «слабые» точки разработки приложений (WIN32 и Web), используя Delphi и компоненты с учетом данных (из стандартного набора Delphi или стороннего)?

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

Но есть также много других RDBMS (MySQL, MSSQL, DB2, Oracle, SQLite, Nexus, Paradox, Interbase, Firebird и т. Д.). Если вы разработали крупные проекты, на которых вы использовали много компонентов с учетом данных, пожалуйста, ответьте с типом базы данных и названием компонентов с учетом данных.

Я также заинтересован в DB2 (AS400). Какие компоненты вы использовали с успехом или какие компоненты действительно больно для работы?

Это было полезно?

Решение

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

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

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

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

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

Другие советы

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

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

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

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

  • Tdatasets принадлежат к Tdatamodules, в то время как TdataSources принадлежат к Tforms (если не используется для отношений с мастер -/детализацией).

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

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

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

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

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

  • Вложенные таблицы TclientDataset полезны, но не единственный способ выразить мастерские отношения. Иногда лучше сделать старый путь с двумя независимыми tclientdatasets, соединенными через TdataSource.

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

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

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

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

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

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

-Джеруен

Компоненты Delphi-Aware не зависят от двигателя Back-End Database, который вы используете, поэтому использование Firebird или MS SQL Server или Oracle или других или других не имеет значения для ваших компонентов, оснащенных данными. Они знают только компонент данных, назначенный им, и делают все свои вещи, связанные с DB через это.

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top