Database “如何使用数据感知控件”；“正确吗？”；？

我想问问有经验的用户，您是喜欢使用数据感知控件在DB中添加、插入、删除和编辑数据，还是喜欢手动操作

我开发了一些数据库应用程序，为了“用户友好策略”，我在其中遇到了复杂的表事件web（afterinsert、afteredit、after…、beforeedit、beforeinsert、before…）。在那之后，调试应用程序是一项相当棘手的工作

意识到这一风险（后来被另一个应用程序发现），我试图避免这个问题，所以我更加注意编写可读性好、全面的代码。从一开始看起来一切都很好，但在发送和加载数据之前，我需要处理一些预处理的事情，所以我又遇到了同样的问题，“缓慢而不可避免”。有时我无论如何都不能使用dataaware控件，而DAControl一开始似乎很“酷”的功能最终变成了一个障碍。我“不得不”为非dataaware控件编写特殊的例程，以便表现为dataaware。然后我问自己，我到底为什么要使用dataaware控件？在非数据感知控件上找到应用程序体系结构是否更好？当然，编写防bug代码需要更多的时间，但这值得吗？我不知道

我遇到过好几次，就像被诅咒的：天堂在开始，地狱在结束

我不知道，如果我用错误的方法编写DB程序，是否有一些标准的常用做法如何进行。或者这是每个人的共同问题

---

Thanx对于建议和您的体验

秘密应该是数据集参数自动化，您可以创建一个控件，通过主从方式将数据集粘合在一起，只需定义它们之间的连接。当然，这种控件应该以其他一些通用的方式提供表单参数。在这种情况下，调用具有实体标识符的表单时，所有数据集都将以正确的顺序填充，并允许提供者自动更新数据库中的数据

通常，最好将数据集作为具有可选计算字段的表的精确表示形式（fkInternalCalc有时工作得更好，因为它使用行更改而不是字段更改进行更新）绑定到数据感知控件。数据感知控件是最理想的方法，并且不太容易出错。就像在每个方面一样，也有例外

---

如果您必须编写太多的粘合函数，那么问题可能是在设计模式中，而不是在VCL中。

我已经编写了使用数据感知组件来对抗TTable样式组件的应用程序，以及使用非数据感知组件的应用程序

现在我的首选是使用数据感知组件，但使用TclientDataSet，而不是TTable样式的组件

---

使用TClientDataSet，我不必让我的用户界面结构模仿我的数据库结构。它足够灵活，可以用多个表中的数据填充它，然后当您将更新应用回数据库时，您可以根据需要手动添加/删除/更新记录。

很多时候，我使用数据感知控件链接到内存表（kbmMemTable），该表是通过查询填充的

我看到的好处是：

我完全控制对数据库的所有插入/更新/发布/编辑

无需担心用户在更新模式下留下记录（可能会锁定其他用户）

我提到过对所有插入/更新/发布/编辑的完全控制吗

使用内存表非常简单，如下所示：

dataset.sql.add('select a.field,b.field from a,b');
dataset.open;
inMemoryTable.loadfromdataset(dataset);
inMemoryTable.checkpoint;

然后“解析”回数据库，您可以访问每个记录中每个字段的原始数据和新数据（类似于触发器）-即使最终用户花了30分钟填写数据感知控件，您也可以在毫秒内轻松完成事务处理并解决整个编辑问题。

您是否考虑过类似Delphi或

---

这将使业务域逻辑与数据库层分离。对于大型和旧式系统，添加另一层，即“”，以保护模型不受数据库设计更改的影响，这一点甚至很常见。

Wayne Niddery在其文章“良好的面向对象设计是否可以包括数据感知控件？”中对此进行了描述，您可以在文章部分找到。