在Delphi中使用DB Aware控件而不是非DB Aware控件有什么好处

Question

我会说服一位朋友，在开发数据库应用程序时，使用Delphi中的使用数据库组件（DB Aware Controls）是最好的选择。

这个争论始于他很多年前：现在他仍然相信使用简单的控件如TEdit，TStringGrid等，用一套getter和setter方法填充它们，是灵活性方面的最佳解决方案。整个项目的可维护性。

对我来说，这听起来至少是违反直觉的。

我认为在开发数据库应用程序时，使用DB Aware控件（如TDBEdit，TDBGrid等）是正确的做法。

所以：请帮助我说服他使用DB Aware Controls的声音建议！

提前感谢所有发表至少他自己建议的人，无论是支持一种解决方案还是其他解决方案。

- fabio vitale

Answer 1

DB-Aware与非DB-Aware是一种过时的讨论。 DB-Aware控件具有自动数据绑定功能，这意味着它们可以自动填充数据，更改检测并写入有限数据源的成员;在非dbaware控件中，由您来完成这些任务。这可能会导致代码混乱 - 或者过度设计框架只是为了进行数据绑定。这两种情况都不好。

数据源的类型和单个控件的质量将决定性能。我已经看到很多代码来对数据绑定TStringGrid只是为了避免TDBGrid因为纯粹主义（当TDbGrid做得很好时） - 只是过于荒谬的时间损失。

当TClientDataset成为断开连接的应用程序的事实数据集时，它成了一个过时的讨论：您可以提取数据，断开连接，处理数据，再次连接并应用更改。由于CDS + DbAware控件将执行99％的接口，因此您可以将非数据感知控件用于下一个1％（对于某些复杂接口）。

我仍然没有XE2来查看LiveBindings是否能很好地完成OO数据绑定 - 如果是这样的话，现在所有控件都可以在需要时识别数据库。

编辑：在da-soft的回答中，他（她？）认为DbAware控件实现了MVC模式，LachlanG不同意，即使它确实如此，代码本身也不是MVC。我会在这里给我0,02美分; - ）

我认为在DataModule和Entity中使用1：1关系（如在ERD中） - 或DataModule和Form - 您可以获得责任分离的应用程序：

• 表格dfm - ＆gt;布局和设计时数据绑定（仅限数据源）
• form * .pas - ＆gt;控制接口并向数据模块询问数据（像控制器一样）
• 数据模块 - ＆gt;回答表单请求数据检索的方法 和数据更新

我通常有一个用于数据库连接的独立数据模块，它通过表单/实体的属性传递。

Answer 2

DB-aware控制专业人员：

1. 将数据加载到控件并将数据保存到数据集的工作由VCL执行。你的代码更少 - 真的是RAD。
2. DB-aware控件+ TDataSource + TDataSet实现MVC模式。这有助于分离GUI和数据访问代码。
3. 使用事件处理程序在明确定义的时刻调用代码验证，重新格式化，对数据进行其他后处理。这有助于集中这些代码并避免与应该放置它的位置混淆。并且避免因为何时调用它而产生混淆。

缺点：

1. 这不是一种普遍的做法。您无法将DB-aware控件绑定到非TDataSet数据源。通过在Delphi XE2中引入实时数据绑定解决了这个问题。
2. 事件驱动的编程可能会让一些开发人员感到困惑。并且需要TDataSource，TDataSet，TField事件和架构的知识，并引起与Pros（3）的争议。糟糕的事件驱动代码可能是噩梦。

Answer 3

DB-aware和非DB-aware组件都有优点和缺点，具体取决于您正在开发的应用程序类型。

对于中小规模的应用程序，鼓励使用支持DB的组件，除非这些应用程序正在运行的特定要求或条件。例如，使用支持DB的组件可以更容易地开发和维护简单的数据输入应用程序。即使是中等规模的应用程序，如果设计和实施得当，也可以通过支持DB的组件获得良好的性能。

但是，在开发模块化应用程序（尤其是多层系统）时，支持DB的组件会对应用程序性能和可维护性产生负面影响。对于通过Internet访问数据的应用程序，这一点尤其明显。主要原因是因为支持DB的组件需要与数据库保持连接，这会显着增加网络流量。

使用非DB感知组件可能更复杂，因为它需要更好地理解底层机制，但在多用户和分布式多层环境中，它比其他任何东西都要好得多。此外，您可以（并且应该）将数据访问层与表示（UI）层分开，稍后将允许您对一个子系统（模块，层）进行更改，而无需更改任何其他内容。

今天，数据可以在任何地方，大部分时间都不存储在本地计算机或网络上。使用DB-aware组件访问该数据可能会对应用程序和数据库性能产生严重的负面影响。有一些数据访问层可以改善这一点（UniDAC，AnyDac，...），因此使用带有它们的DB感知组件可以获得更好的性能。不过，非DB感知组件仍然可以胜过任何事情。

由开发人员决定使用哪种机制，因为正如我所说，这完全取决于您正在制作的应用程序类型以及它将在何种环境中运行。

Answer 4

这可能是Visual Basic体验的延续。我记得，即便是微软也告诉开发人员不要在生产代码中使用DB-aware控件。

Delphi从未遇到过这个问题，但正如其他人所说，这取决于您正在构建的项目类型以及是否遇到性能问题。

Answer 5

轶事：数据库感知控件一旦弄乱我们的InterBase数据库：为了表示'空'或空日期，日期编辑控件TcxDBDateEdit（ExpressQuantumGrid）使用负日期值，它代表字面意思是“01/00/0000”。

因此，当用户清除输入表单中的日期编辑字段并将此值发布到数据库时，记录变得不可读（SELECT语句失败）。