使用Delphi数据感知组件 - 优点和缺点

时间:2011-01-18 09:41:05

标签: oracle delphi firebird ibm-midrange data-aware

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

使用FireBird我已经使用了IBObjects,它是一个成熟的组件套件并且运行良好。

但是还有很多其他RDBMS(MySQL,MSSQL,DB2,Oracle,SQLite,Nexus,Paradox,Interbase,FireBird等)。如果你已经开发了大型项目,你已经使用了很多数据感知组件,请回答数据库类型和数据感知组件套件名称。

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

7 个答案:

答案 0 :(得分:20)

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

这适用于小型项目,但随着它们变大,代码变得越来越难以维护。

所有各种事件代码(及其相互作用)都可能成为真正的噩梦!

在这种情况下,我总是抛弃了数据感知组件,并转而采用(手工编码)MVC设计。

这需要大量的前期编码工作,但结果(IMHO)在可维护,可扩展和可调试的项目中。

答案 1 :(得分:13)

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

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

  • 不要只是在更大范围内重写FishFact。把想法放到你的设计中。

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

  • TDatases属于TDataModules,而TDataSources属于TForms(除非用于主/细节关系)。

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

  • 您的ClientDataSets不必完全镜像数据库表。 DataSnap允许您在内存中按摩数据结构,以便生成为特定目的而定制的数据集。具体来说,你可以做像

    这样的事情
    • 将两个或多个表连接到一个可编辑数据集

    • 对主细节表结构进行非规范化,有时可以简化您的UI代码。

    • 创建仅限内存的字段(如计算字段,但您也可以写入它们)

  • TClientDataSet嵌套表很有用,但不是表达主细节关系的唯一方法。有时最好通过TDataSource连接两个独立的TClientDataSets以旧方式完成。

答案 2 :(得分:6)

看看ORM解决方案。

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

答案 3 :(得分:6)

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

这并不难,但你需要知道如何做到这一点。

一种方法是将DataSet组件放在DataModule(或其他非可视容器)中。

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

- 的Jeroen

答案 4 :(得分:3)

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

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

答案 5 :(得分:3)

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

Remobject SDK相结合,您将拥有n层架构和数据库抽象的完美结合。

答案 6 :(得分:3)

从RAD和原型设计的角度来看,数据感知组件非常有用,特别是当您设计基于数据的报表或网格时。即你可以在设计时修补一下。 所以我就这样使用它们。但是,当需要将其转换为运输代码时,我几乎总是切断连接,从查询中删除SQL,并在代码中执行所有操作。这种方式更具可预测性和可维护性,尤其是在具有版本控制的多开发人员环境中。当SQL以某种形式嵌入到表单中时,尝试找出SQL实际驻留的位置是一件很大的痛苦。在两个地方安装SQL尤其糟糕,然后必须弄清楚哪个有效。