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

介绍

Delphi是一个非常强大的开发商业应用程序的工具。通过使用数据控件和其它VCL库，我们可以迅速地做出强壮而高效的小型应用程序。然而，开发复杂的应用程序有其特有的难题。小型部门级的应用程序相比企业级应用程序能从RAD开发方式中获得更多好处。在业务规则，数据，用户界面之间存在着复杂交互的大型C/S应用程序需要对设计有更多的关注，而不能仅仅满足于RAD.然而不管怎样， Delphi都是建立企业级应用程序非常好的工具。

 

开发企业级应用程序独特的挑战在于，在这个PC时代(相对于主机时代，译者注)，大部分公司的数据处理是分散的。使用RAD和其它用户友好的工具开发的小型的廉价的应用程序逐渐地取代了大型主机/终端结构的程序，那些程序代码长，改动困难，而且开发维护费用昂贵。由于这种分散结构，现今有很多程序是部门级和工作组级别的。得益于程序的小型化和开发工具的进化，有很多信息部门的人员不是IT科班出身。虽然，在很大程度上，这是一个好的演变，但是目前我们面对的是大量的冗余数据和业务规则，相同的数据被各种不同的应用程序以不同的方式存储。更加麻烦的是，在各种不同的系统中往往存在相同的考量。解决这些问题的方法要重复多次。为了保持业务规则的同步，所有相关应用程序都必须同步更新，通常这是很困难的。

 

　　现今的商业环境改变非常迅速，这些问题困扰着信息系统的开发者。现今的市场需要可以随时修改的高度灵活的信息系统。对于RAD开发方式，开发时的确比较迅速，但是，当需求和规则改变后，对软件的修改却比较缓慢。RAD容易造成一种只懂点皮毛就可以开始做的心理，这对开发来说，不是一个好习惯。由于“时间紧迫”，开发者往往把业务规则放在用户交互界面中。这些相同的规则由于在不同的地方要重复实现，他们喜欢把代码在不同的窗体和不同的事件中到处拷贝。在不同的应用程序和同一个程序不同的部分都可以看到这种本应该相同的规则，作为结果，业务规则存在着潜在的不一致，并且很脆弱。

 

企业发展的难题不仅仅在于开发良好的强壮的应用程序，我们必须在战略上来计划软件的开发者和终端用户存取企业数据和业务规则。为了能够给企业开发强壮可靠的软件系统，良好的工具和良好的设计缺一不可。问题的范围和解决的方案是个很大的话题，不可能在这个演讲中解决。我不会怀疑有人有很好的解决方案，也不会质疑该方案是否符合所有组织的需求。在此，我想呈现一个方案的例子――集中化业务规则，并且将概括叙述我们如何实现这个方案。

考察当前C/S计算方式的局限

RAD 胖客户方案

Delphi是一个绝佳的RAD/原型工具，开发者可以使用它迅速地开发可靠的应用程序。不同于典型的RAD项目，开发面向对象的MIS系统，需要相当多的计划和设计。RAD开发方式有它自己的适应范围：小型mis程序，原型开发，工具软件。在这三种情况下，RAD方式很好。但是，在开发企业级的mis系统时，这种方式会暴露出一些弊端。

在RAD开发方式中，把业务规则绑定到用户界面中是一个很自然的思路。举个例子：在一个控件的onexit事件中，检查它的值是否大于其它某几个控件的值的总和，如果满足则通过，否则不给保存，并抛出一个异常。但是，我们假设用户没有操作这个窗体而是用了另外的窗体，则这个检查的规则将不会执行。你永远不能确保所有的业务规则能够被执行。如果把业务规则绑定在用户界面中，当业务规则变得复杂起来时，它的维护就会变得很困难。你不得不仔细查找每一个用户可能交互的窗体，仔细查看每一个可能的控件事件，以确保每个可能的操作都不会符合新的业务规则。

另外一个考虑是代码重用，这可以通过建立一个中心的业务规则存储地方来解决。如果你把业务规则放在用户交互的窗体中，则很难被重用，除非该窗体也被用在其它应用程序中。一般开发用户拥抱RAD的主要理由是RAD可以节省大量“计划”的时间。在这个“节省下来的时间”里，他们把代码四处拷贝。其实你可以设计一个类来控制业务规则。

软件产业专家估计很多公司花费最初开发费用4-10倍的金钱用于维护软件（维护费用大大高于开发费用，译者）。当把业务规则写在GUI交互界面中时，每改动一次，维护人员就要找遍所有的源代码，然后更改全部涉及的地方，一处都不能漏掉。作为替代，如果把业务规则写在一处地方，则可大大减少维护费用。容易查找，因为只找一处，容易修改，因为只改一处。

把业务规则写在客户交互界面中还有一个弊端，当业务规则改变时。客户端软件的所有部分都要更新。在一个大企业中，有时更新一个软件的总体费用甚至超过重新写一个新的程序。这种胖客户方案在灵活性，伸缩性，可量测性方面都会有一些问题。

胖服务器方案

有很多客户/服务器的应用软件使用胖服务器样式。在胖服务器系统中，所有的业务规则都假定包含在后端数据库服务器的存储过程和触发器中。我认为这种方式同样有一些问题，为使业务规则“传播出去”，同样的规则会在客户端用客户端语言代码重写一遍，因而有人又只好把规则放客户端用户界面，而省掉服务器端。

作为一般的原则，在后端服务器通过存储过程和触发器实施业务规则要好过胖客户端方案。对于所有的客户端，在存取数据更新数据时强迫执行这些业务规则的确要好过仅仅把业务规则放在客户界面中。集中这些业务规则的代码同样带来一定的重用性。

普遍的，对很多商业应用程序要求的复杂数据处理，服务器端的语言不适合用来做这个事情的，服务器端的语言主要用于数据的存取而不是逻辑处理。有SQL92,T-SQL或者PL/SQL语言经验的程序员，可能有能力在后端写复杂地处理逻辑。但是在后端写存储过程很难修改和维护。对于类似ORACLE的j/sql一类的语言，它们是面向对象的，有可能在不久的将来我们可以做到在服务器端很容易写商业逻辑。

服务器的本性不是交互式的。在70年代，终端把一大把数据扔到大型或者小型主机，然后等待主机在终端上显示，告诉用户有什么不妥的地方。而今，用户希望电脑提示他（她）应该输入什么样的数据，告诉他输入的数据错在什么地方，他希望在一个订单的明细输入过程中，电脑不断地告诉他目前的商品数量和金额总和是多少，而不是全部输完了，天啊，发现错了，全部重来。时代不同了！

基于服务器端的代码很难排错。缺乏集成调试器，没有观察窗和其它现代调试工具，这一切使得服务器端代码难写难维护。服务器端本身是设计用于存取数据的，现在却把维护业务规则的责任也丢给了它，它被迫使用很多CPU周期去做本不应该它做的事情，这可能会带来一些性能问题。当它忙于处理业务规则时，查询和更新数据的速度就会受到影响。