使用 Delphi 数据感知组件 - 优点和缺点 [关闭]

Posted 2023-02-16

【中文标题】使用 Delphi 数据感知组件 - 优点和缺点 [关闭]

【英文标题】：Using Delphi data-aware components - pros and cons [closed]

【发布时间】：2011-06-10 23:44:39

【问题描述】：

我想知道您对在项目中使用数据感知组件的看法。使用 Delphi 和数据感知组件（来自 Delphi 的标准套件或第三方）开发应用程序（win32 和 web）的“优势”和“劣势”点是什么？

使用 FireBird，我使用 IBObjects 进行了很多工作，IBObjects 是一套成熟的组件并且运行良好。

但也有很多其他的 RDBMS（mysql、MSSQL、DB2、Oracle、SQLite、Nexus、Paradox、Interbase、FireBird 等）。如果您开发了大型项目，并且在其中使用了很多数据感知组件，请回答数据库类型和数据感知组件套件名称。

我也对 DB2 (AS400) 感兴趣。您成功使用了哪些组件，或者哪些组件真的很难使用？

【参考方案1】：

我发现使用数据感知组件会导致应用程序没有明确区分业务逻辑和 UI 逻辑。

这对于小型项目来说很好，但随着它们变得越来越大，代码变得越来越难以维护。

所有不同的事件代码（及其交互）都可能成为真正的噩梦！

在这种情况下，我总是放弃数据感知组件，转而使用（手动编码的）MVC 设计。

这确实需要大量的前期编码工作，但结果（恕我直言）在一个可维护、可扩展和可调试的项目中。

【讨论】：

这是 RAD 方法的限制之一：很高兴有一些东西可以快速运行，但有时不如面向代码的解决方案强大和可维护。

+1 作为一个习惯于“手工编码”MVC 风格的开发人员，目前正在开发数据感知控件，我完全同意。有大量重复的代码，有时还有一堆乱七八糟的事件处理程序。

我忘了提到，为了连接到 Oracle，我使用了来自 allroundautomations.com 的“直接 Oracle 访问”。如果您想使用 Oracle 特定的功能，那么一组很棒的组件。如果您想保持与数据库无关，那根本没有用。

请注意，它不是非此即彼的。虽然我的主要业务代码是 MVC 风格的框架（同时支持 Web 和客户端），但我仍然使用快速 RAD 方法，例如系统管理工具。

【参考方案2】：

看看 ORM 解决方案。

这是多层架构的好方法。见ORM for DELPHI win32

【参考方案3】：

Delphi 数据感知组件不依赖于您使用的后端数据库引擎，因此使用 Firebird 或 MS SQL Server 或 Oracle 或其他对您的数据感知组件无关紧要。他们只知道分配给他们的数据源组件，并通过它完成所有与数据库相关的工作。

对我来说，如果可以以一种不错的方式使用数据感知组件完成某些事情，我会使用它们。这些通常是应该在短时间内完成的小项目。在更大的项目中，我可能会完全排除数据感知组件，或者将它们用于仅用于数据呈现且不接收用户输入的表单中。在接收用户输入时，我可能会使用非数据感知组件，因为我可以更灵活地控制它们并验证输入。当然，数据件组件在这种情况下也仍然有用。您仍然可以在 OnBeforePost 等数据集事件中验证用户输入。此外，如果您使用的是多层设计，并且您的客户端应用程序代表数据呈现层，则您的输入验证在中间层完成，因此您可以使用客户端应用程序中的数据感知组件接收输入，并将它们发送到用于验证和进一步处理的中间层。

【参考方案4】：

您可以使用Unidac，它支持许多数据库服务器，包括Firebird（我使用的）并且具有非常好的功能。

再加上Remobject SDK，您将拥有 n 层架构和数据库抽象的完美结合。

【参考方案5】：

从 RAD 和原型设计的角度来看，数据感知组件非常有用，尤其是在您设计基于数据的报表或表格时。即您可以在设计时进行修补。 所以我就这样使用它们。但是当需要将其转换为交付代码时，我几乎总是切断连接，从查询中删除 SQL，然后在代码中完成所有操作。这种方式更加可预测和可维护，尤其是在具有版本控制的多开发人员环境中。当 SQL 嵌入到表单中的某个位置时，试图找出 SQL 实际驻留的位置是一件非常痛苦的事情。而且特别糟糕的是两个地方都有SQL，然后还要搞清楚哪个是生效的。

【参考方案6】：

数据感知控件很棒，但您必须确保将业务代码放在单独的层中。

这并不难，但您需要了解如何做到这一点。

一种方法是将您的 DataSet 组件放在 DataModule（或其他非可视容器）中。

另一个方便的技巧是使用 TClientDataSet 来执行 UI 条目，并将其用作 UI 和业务层之间的中间缓冲区。然后，业务层使用特定于您的数据层的 TDataSet 组件。

--杰罗恩

【讨论】：

同意。如今，对内存数据集（例如 TClientDataSet）使用数据感知控件是我首选的用户界面模型。正确分层代码需要一些工作和纪律，但它仍然比使用非数据感知控件手动完成所有操作要快。

我认为它最初可能会更快，但从长远来看，它仍然是净亏损而不是胜利。

@WarrenP 请详细说明：我很乐意看到你的观点。

我一直发现完成 90% 所需的精力更少，而当我使用数据感知控件时，最后 10% 总是需要更长的时间，尤其是在系统。其中一些来自您需要学习使用数据感知模型的技巧，还有一些来自我仅在使用数据感知控件时遇到的奇怪故障。

@WarrenP 那么您对此有何看法？它甚至可能需要一个自己的答案:)

【参考方案7】：

在尝试了数据感知和非数据感知风格的 Delphi 应用程序之后，这些天我又回到了数据感知组件阵营。正确分层代码需要一些工作和纪律，但它仍然比使用非数据感知控件手动完成所有事情要快。

我的一些数据感知组件使用技巧是

不要只是大规模地重写 FishFact。在您的设计中加入一些想法。

不要使用 TDataModule，使用 许多 TDataModule，每个 TDataModule 只负责应用程序数据的一小部分。

TDatasets 属于 TDataModules，而 TDataSources 属于 TForms（除非用于主/从关系）。

使用内存数据集，例如 DataSnap TClientDataSet。

您的 ClientDataSet 不必完全镜像您的数据库表。 DataSnap 允许您处理内存中的数据结构，以便您可以生成针对特定目的量身定制的数据集。具体来说，您可以执行以下操作

将两个或多个表连接到一个可编辑的数据集中

非规范化主从表结构，有时可以简化您的 UI 代码。

仅创建内存字段（类似于计算字段，但您也可以写入它们）

TClientDataSet 嵌套表很有用，但不是表达主从关系的唯一方法。有时最好使用旧方法，通过 TDataSource 连接两个独立的 TClientDataSet。