在 Delphi 中分离数据访问、业务逻辑和 GUI 的任何建议

Posted 2023-02-24

【中文标题】在 Delphi 中分离数据访问、业务逻辑和 GUI 的任何建议

【英文标题】：Any suggestions for separating data access, business logic and GUI in Delphi

【发布时间】：2010-10-24 19:23:09

【问题描述】：

我想将数据层与业务逻辑和业务逻辑与 GUI 分开。潜入网络我偶然发现了一些资源，但仍然无法让我的想法清晰。有些人谈论模式，有些人则指向各种框架。 我的要求是：

从 rdbms（主要是 mysql）CRUD 操作中操作数据 处理 id 生成（我应该使用自动增量或提供的数据引擎还是生成的 pascal 代码） 表关系可以是逻辑的（不使用参照完整性）也可以不是 需要能够从数据模型生成对象关系 必须将数据转换为业务对象并操作业务逻辑 应使用现有的 gui 组件或免费软件的组件

我需要的是：

带有基本示例代码/应用程序布局（例如单元类-模块-目录）的一些指导技术/建议...不是 OOP 方面的专家，当我必须设计类层次结构时会感到困惑 带有教程的简单框架 甚至您自己的日常代码/框架/方法

【参考方案1】：

由于您使用的是 Delphi，因此请务必查看 DataModules。这是您放置数据库访问组件和逻辑的地方。

将类放在普通的“单元”文件中。

让 UI 与这两者对话以使事情发生。您可以直接在表单上使用数据库访问组件，但这最好作为“仅显示”模式并使用数据模块对数据进行操作。 （您可以为基本应用程序在表单上做任何事情，但如果您想模块化应用程序，将其分开是明智的）。

【参考方案2】：

帮助实施这种分离的一种简单方法是为您的业务逻辑编写单元测试。除了其他（实质性）好处之外，使代码可测试意味着它不能（有意或无意地）与 UI 紧密耦合。

我尝试（但并不总是成功）通过使用 ClientDataSets 将数据层的细节分开，而不管后端使用的是什么（通常是 DBExpress 或 DBISAM）。我还尝试编写至少一些集成测试以确保数据层按预期工作（具有已知值的单独测试数据库）。

有了业务逻辑和数据（即使是部分），用户界面就更加直接。并且可维护。

【参考方案3】：

看看tiOPF

【参考方案4】：

我个人使用tiopf 作为商业模式。 Tiopf 提供数据访问层。存储库中的最新代码包括一个类似于 MVC 的模型-gui-mediator 框架，用于显示模型。这允许您使用标准的 delphi 组件显示您的数据。

Tiopf 还包含许多 ID 生成器（guid、32 位和 64 位整数等）。

如果你对 tiopf 感兴趣，我建议你先看看我的overview。然后将任何问题发送到新闻组。

【参考方案5】：

尝试使用开源InstantObjects，您将始终希望将其用于 Delphi 中的各种数据库编程。

在 IO 中，您必须在其接口中定义整个数据结构，然后它会为您生成必要的代码。

试试吧。

至于 id Generation 信任 MySQL 为您生成一个自动增量 id。不要花时间编写代码。

【参考方案6】：

我使用并且效果很好的一种方法是尝试从您的应用程序中扮演不同的角色，然后像您扮演那个角色一样进行编程。例如，当您在数据库后端工作时，甚至不要考虑 gui。而是考虑公开只处理数据的类和方法。如果您制作自己的 SDK 供以后使用，您会发现维护起来会容易得多。

基于测试的开发是您的朋友。了解 DUnit，并创建简洁的小测试来练习任何重要的代码。记录接口，以及通过查看满是代码的屏幕不明显的任何内容。

【参考方案7】：

我会看看 Model-View-Controller（它是 Observer / Observable 模式的扩展）。这意味着“视图”（即 UI）只知道如何更新数据，然后响应正在更新的数据。 Model（或 Observable）知道如何操作数据并告诉 Views 它已被更新。这意味着您可以替换 UI 而无需更改数据提供者，反之亦然。

在 Google 上进行搜索，因为 Delphi 有很多这样的例子（但对于 Java / C# 等来说没有那么多）