我想知道您对在项目中使用数据感知组件的看法。使用 Delphi 和数据感知组件（来自 Delphi 的标准套件或第三方）开发应用程序（win32 和 web）的“优势”和“劣势”是什么？
使用 FireBird，我在 IBObjects 上做了很多工作，IBObjects 是一套成熟的组件并且运行良好。
但也有很多其他 RDBMS（MySQL、MSSQL、DB2、Oracle、SQLite、Nexus、Paradox、Interbase、FireBird 等）。如果您开发了大型项目，并且在其中使用了很多数据感知组件，请回答数据库类型和数据感知组件套件名称。
我也对 DB2 (AS400) 感兴趣。您成功使用了哪些组件，或者哪些组件真的很难使用？
我发现使用数据感知组件会导致应用程序在业务逻辑和 UI 逻辑之间没有明显区别。
这对于小型项目来说很好，但随着它们变得越来越大，代码变得越来越难以维护。
所有各种事件代码（及其交互）都可能成为真正的噩梦！
在这种情况下，我总是放弃数据感知组件并切换到（手动编码的）MVC 设计。
这确实需要大量的前期编码工作，但结果（恕我直言）在一个可维护、可扩展和可调试的项目中。
在尝试了 Delphi 应用程序的数据感知和非数据感知风格之后，我这些天又回到了数据感知组件阵营。正确分层代码需要一些工作和纪律，但它仍然比使用非数据感知控件手动完成所有事情要快。
我的一些数据感知组件使用技巧是
不要只是大规模地重写 FishFact。在你的设计中加入一些想法。
不要使用 TDataModule，使用许多TDataModule，每个 TDataModule 只负责应用程序数据的一小部分。
TDatasets 属于 TDataModules，而 TDataSources 属于 TForms（除非用于主/从关系）。
使用内存数据集，例如 DataSnap TClientDataSet。
您的 ClientDataSets 不必完全镜像您的数据库表。DataSnap 允许您处理内存中的数据结构，以便您可以生成针对特定目的量身定制的数据集。具体来说，您可以执行以下操作
将两个或多个表连接到一个可编辑数据集中
非规范化主从表结构有时可以简化您的 UI 代码。
创建仅在内存中的字段（如计算字段，但您也可以写入它们）
TClientDataSet 嵌套表很有用，但不是表达主从关系的唯一方法。有时最好使用通过 TDataSource 连接的两个独立 TClientDataSet 的旧方法。
看看 ORM 解决方案。
这是多层架构的好方法。参见DELPHI win32 的 ORM
数据感知控件很棒，但您必须确保将业务代码放在单独的层中。
这并不难，但您需要了解如何做到这一点。
一种方法是将 DataSet 组件放在 DataModule（或其他非可视容器）中。
另一个方便的技巧是使用 TClientDataSet 来执行 UI 条目，并将其用作 UI 和业务层之间的中间缓冲区。然后，业务层使用特定于您的数据层的 TDataSet 组件。
——杰伦
Delphi 数据感知组件不依赖于您使用的后端数据库引擎，因此使用 Firebird 或 MS SQL Server 或 Oracle 或其他对您的数据感知组件无关紧要。他们只知道分配给他们的数据源组件，并通过它完成所有与数据库相关的工作。
对我来说，如果可以以一种很好的方式使用数据感知组件来完成某些事情，我会使用它们。这些通常是应该在短时间内完成的小项目。在更大的项目中，我可能会完全排除数据感知组件，或者将它们用于仅用于数据呈现且不接收用户输入的表单中。在接收用户输入时，我可能会使用非数据感知组件，因为我可以更灵活地控制它们并验证输入。当然，数据件组件在这种情况下也仍然有用。您仍然可以在 OnBeforePost 等数据集事件中验证用户输入。此外，如果您使用多层设计，并且您的客户端应用程序代表数据呈现层，则您的输入验证在中间层完成，因此您可以使用客户端应用程序中的数据感知组件接收输入，
您可以使用Unidac，它支持许多数据库服务器，包括 Firebird（我使用的）并且具有非常好的特性。
结合Remobject SDK，您将拥有 n 层架构和数据库抽象的完美结合。
从 RAD 和原型设计的角度来看，数据感知组件非常有用，尤其是在您设计基于数据的报表或网格时。即你可以在设计时修补。所以我就这样使用它们。但是当需要将其转换为交付代码时，我几乎总是切断连接，从查询中删除 SQL，然后在代码中完成所有操作。这种方式更加可预测和可维护，尤其是在具有版本控制的多开发人员环境中。当 SQL 嵌入到表单中的某个位置时，试图找出 SQL 实际驻留的位置是一件非常痛苦的事情。而且在两个地方都有SQL尤其糟糕，然后必须弄清楚哪个是有效的。