在delphi中开发业务对象(3)

靠近了-在Delphi中开发业务对象

Enough theoretical说到：现在，让我们来点实际的，怎样在Delphi中开发应用程序时使用业务对象？好的，我们开始设计吧。我先来介绍一个简单的业务问题域，后面当我们讨论建立业务对象时，它作为我们的基础。

下面我建立一个真实的面向对象的系统—银行，用这个例子来演示一下业务对象的能量。我来演示如何封装业务逻辑，并且建立一系列的类。你将看到，这些都是很典型的业务应用程序可能要做的。

我将从如何提取代表真实商业问题域的类。就面向对象开发来说，提取类别，并且把商业问题域分解到类和对象中是一件最关键的，也是一件最困难的事情。由于我们提取的类决定了应用程序的灵活性和可扩展性，恰当地划分问题域到几个不同的类中是很关键的。你所开发的应用程序的行为就由这里划分的类之间的交互来决定。当类已经定义好并且发布接口后，再来分割类的功能进行重构是很困难的。

 

下面是提取类的一般性原则的指引

它是不是物理实体？（账单，车辆，地理位置等等）

软件用户是否提到这个概念的名字？（电话呼叫？接见？）

是否该对象会包含其他实体？（驾驶证里面记载了一个人，但是驾驶证本身并不是人，因此驾驶证对象可能包含一个人的对象）

他是否仅仅只是一个软件开发过程中使用的对象，而不是应用程序本身的功能？（通过一个对象去查询另外一个对象在软件中常见，但不一定是一个真实世界的功能，视具体问题而定）

 

探索Delphi的力量

Delphi主要是一个基于关系数据库/数据集的工具。Delphi的主要能力是，首先是一个快速应用程序开发工具－RAD,同时具备良好的访问关系数据库的能力。经过良好构造的Delphi程序是严密的，快速的，灵活的，并且只需要写少量代码。

 

传统Delphi开发中的不足

在企业级应用软件开发过程中，Delphi的优势可能会变成一个绊脚石。由于组件丰富，可以迅速搭积木组成应用程序，导致很多人不重视前期设计。很多本来只能用于原型的代码结果直接就放到了产品代码中，把原型程序随随便便就变成了上线的程序。这样一来问题便出现了。首先，是表示层和数据访问层耦合太过紧密，快速原型开发方法导致代码可重用性非常低，而且业务逻辑被生硬地写在了表示层中。

数据感知控件加速了应用程序开发，但同时也将表示层绑在了数据集控件上。即使通过数据模块来绑定数据集仍然造成对象间的相互依赖过强。由于这个原因，表示层和数据访问层不大可能单独发布。于是，开发者倾向于干脆就在表示层中写代码，也就不打算任何重用了。另外开发中的可视化设计方式也容易引导我们在用户交互界面中写业务规则。使用可视化开发的应用程序也容易导向基于数据而不是基于方法。

 

Delphi中的“纯”业务对象

基于业务对象的开发首先应该是基于方法的，而不是基于数据的。当我们解耦业务对象后，它们仍然能在系统的其它地方使用。一个纯的业务对象是完全独立并且…(不会翻译，原文是:A pure business object is a fully independent and communicative entity that can be inherited)，用这种方式写代码在Delphi中无疑是可能的，当然这种方式也不会充分享受Delphi的便利。这儿有一个例子，我们来看看它是什么样子的：

 

type Tperson = class(TObject)
  private
     fName : String;
     fBirthDate : TdateTime;
     fFather : TPerson;
     fMother : TPerson;
  protected
  public
     procedure setMother(mother : TPerson);
     function getMother : TPerson;
     procedure setFather(father : TPerson);
     function getFather : TPerson;
  published
     property Mother : Tperson read getMother
        write setMother;
     property Father : Tperson read getFather
        write setFather;
     property Name : String read fName
        write fName;
     property BirthDate : TdateTime
        read fBirthDate write fBirthDate;
     end;

注意到上面这个对象不是基于数据集的，它由真实世界建模而来，是一个纯的对象实现。这是一个人的对象，你可以询问他（她）而找到跟他相关的人，比如他的父母亲等。但是在这里没有数据集中的那些上一下，下一个，最后一个这些概念。这个人的属性照字面意义写在那儿（姓名，生日等）。由于你还得将这个人的信息存放在关系数据库中（关系数据库绝对是目前的主流），因此你还得处理对象/关系的映射（O/R Mapping）.对于java和C++程序员来说，有一些比较成熟的O/R Mapping工具，但是，对Delphi来说，比较少，也不太成熟。

 

在Delphi中以这种写对象的方式来开发程序，面向对象是很纯了，但是又不能充分发挥Delphi最初设计给她的优势了。这个优势就是整合了高效关系数据库访问机制，和通过VCL提供了高级的数据绑定。当然你也可以为你自己的业务对象提供自己的绑定机制，通过将自己的业务对象做成抽象类TdataSet的派生类就可以达到目的。这听起来不是一个坏主意，能够免掉很多重复的手工绑定代码。用这种方式绑定单值的控件并不困难，但如果打算绑定多值控件如Grid,那真是一个挑战。

这种方式的设计又带来另外一个麻烦，当业务对象的某个值改变后，没有对象来通知你。因为你没有把界面控件注册为一个监听器，当业务对象改变后，用户界面不知道要重新从业务对象中取值并将其呈现出来。

我并不是说上面的问题没有办法解决（我自己就完成了这个任务）。但是这样一来要做很多额外的工作，软件开发周期也将被拉长。Delphi是一个可视开发工具，做这些事情对大部分人来说，似乎前景并不吸引人。

难道在Delphi中可视开发环境天生就不适合使用业务对象？当然不是，业务对象的好处能在Delphi的基本上得到实现，并且就在Delphi中，无须假借他求，就在可视化设计中就能使用业务对象。