delphi - Delphi 重构示例，涉及可直接访问数据库表的数据感知控件和数据模块

Question

我正在尝试定义重构我正在从事的项目的最佳方法。

由于缺乏良好的设计，几乎所有项目都是由以下组成:

1)包含业务逻辑的表单

2)巨大的数据模块(每个表单 1 个 + 一些额外的)

3)一些包含公共(public)代码(库)的单元

没有面向对象编程(除了一些小区域)，代码重用处于最低水平。

还有一个问题是使用了数据感知控件，因此可以非常简单地将许多数据集+数据源放在数据模块上，并以高度耦合的方式直接链接到数据库。

理想情况下，我想提取类，如 TCustomer、TEmployee，以获得操作系统封装的优势，并使得将来可以创建新的 UI，而无需复制所有代码。

无论如何，我的问题是:我如何才能继续处理数据感知控件？我是否应该实现一个返回数据集的函数，并将 dataawarecomponent.datasource 链接到函数结果？

function TCustomer.LoadByID(aCustomerID: integer): TDataset

？

Answer 1

您必须遵守应用程序设计所围绕的架构。不要试图对抗它。让数据感知控件做它们擅长的事情:数据同步。如果您的控件已经使用 dfm 绑定(bind)到其数据源，那么应该不会有问题。

您需要重构的是附加到控件的所有事件处理程序。我建议你看看Supervising Controller图案。我找到了以下示例实现:

• ASP.NET
• .NET Rich clients (winforms 或 wpf)
• Smalltalk (这是该模式的先驱，并且早于“监督控制者”的标签)

虽然 Delphi 中有一些 UI 架构模式的示例，但那些面向桌面应用程序的示例往往与 Passive View 相关。而不是监督控制者。所以这是我的看法。

您首先需要为应用程序中的每个表单定义至少一个接口(interface)。我说至少一个是因为某些表单很复杂，可能需要分解为多个接口(interface)。

IProductView = interface
end;

然后让您的表单实现它。

TProductForm = class(TForm, IProductView)
...
end;

接下来您需要一个演示者/ Controller 。这将处理除数据同步之外的所有事情。

TProductPresenter = class
private
  FView: IProductView;
public
  constructor Create(AView:IProductView);
end;

在表单类中创建一个私有(private)字段，并在创建/释放表单时创建/释放演示者。无论您使用表单的构造函数/析构函数还是 onCreate/onDestroy 事件都没有多大关系。

TProductForm = class(TForm, IProductView)
private
  FPresenter: TProductPresenter;
public
  constructor Create;
...
end;

implementation
TProductForm.Create
begin
  FPresenter := TProductPresenter.Create(self);
end;

现在，当您需要表单或其控件之一响应事件时，将责任委托(delegate)给演示者。假设您需要检查产品名称是否使用了正确的大写。

TProductForm.NameDBEditChange(Sender: TObject);
begin
  FPresenter.ValidateName;
end;

不是将控件或其文本属性作为参数传递，而是将数据作为界面上的属性公开...

IProductView = interface
  function GetName:string;
  procedure SetName(Value: string);
  property Name: string read GetName write SetName;

...并在表单上实现 GetName 和 SetName。

TProductForm.GetName: string;
begin
  Result := NameDBEdit.Text;
end;

TProductForm.SetName(Value: string);
begin
  NameDBEdit.Text := Value;
end;

以尽可能简单的形式公开数据非常重要。您不希望演示者根据产品名称存储在 TDBEdit 中。演示者应该只能看到您明确允许它通过界面看到的内容。这样做的主要好处是您可以根据需要修改表单(或完全替换它)，并且只要它遵循界面，就​​不需要对演示者进行任何更改。

现在您的所有业务逻辑都已转移到您的演示者，它将类似于一个上帝类。您的下一步将是将逻辑重构为按职责划分的适当类。当您达到这一点时，您就可以更好地尝试架构重新设计(如果您仍在考虑的话)。

“哇!看起来工作量很大!”你可能会说。你是对的(但你知道在开始之前这将是大量工作)。它不必一次完成。这些步骤都不会改变发生逻辑的行为。

优点

• 用户界面现在可以轻松修改
• 可以更轻松地单独测试业务逻辑
• 可以逐步实现

缺点

• 一开始需要更多工作，但最终会被更易于维护的代码所抵消。
• 并不适合所有应用。对于小型项目，额外的基础设施可能不值得付出努力。

其他引用

• A Delphi Implementation of the Model View Presenter Framework (示例是自定义 UI 控件)
• TDD’ing the GUI
• A Simple start with MVP in Delphi for Win32, Part 1 , Part2