【问题标题】:Using Delphi data-aware components - pros and cons [closed]使用 Delphi 数据感知组件 - 优点和缺点 [关闭]
【发布时间】: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) 感兴趣。您成功使用了哪些组件,或者哪些组件真的很难使用?

【问题讨论】:

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


    【解决方案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。

            【讨论】:

              猜你喜欢
              • 2012-03-10
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2011-06-07
              • 2012-03-20
              • 2011-01-03
              • 2012-10-26
              相关资源
              最近更新 更多