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

GUI--Midas物理三层结构

把业务对象移到三层结构的中间层去.业务对象移到第三层包括具体的数据访问业务规则都是在一个应用服务器上进行的.仅仅是最近,把功能分解到多层的开发方式才能被普通的程序员理解和实行.微软在windows操作系统中加入了DCOM, Netscape 也在新版本的Navigator 中加入了分布式的ORB.不久事实上会出现高级通讯协议,来代替目前开发中使用混乱的通讯协议和库文件.

 

物理三层的优势

通过多台机器分开数据处理能提高好的伸缩性.

简化客户端的配置,不需要高性能的客户端.

容易分发应用程序

比逻辑上的三层更少问题.

为你的业务对象提供容错保险.

 

物理三层中的GUI

把中间层的业务对象绑定到客户端与逻辑上的三层类似,但是有一些问题还是不同于逻辑上三层的胖客户,包括相应能力,用户反馈,灵活性,下面具体论述:

 

用户验证的立即反馈,为了使中间层的响应速度接近胖客户的业务对象,从客户来的数据必须有它的主要放置地方,就是中间层业务对象.任何存在客户端的数据都只能使中间层业务对象的一个缓存.这样规则可以很快触发,用户能迅速得到反馈.一个典型的不能正常工作的情形是CGI,你在Form中填入了数,然后提交,如果有什么问题,CGI程序提示你,然后你再重来.如果你去银行申请贷款,这样也许能够接受,如果你整天和这样的程序工作,会很难受.通常Gui界面是由业务逻辑控制的,为什么发票的保存按钮是灰色的?原来是因为总数不等于…你只好发呆了.通常Gui的控制是标准的(如果数据集不处于编辑状态,你不能按保存按钮),但是恰好这些变化是由业务对象的状态所控制的.这也是为什么业务逻辑一定要编码放在一处地方,而且不能违背(不管是在业务对象中还是在数据库中的存储过程和触发器),并且对每一个用户的屏幕来说,都是友好的合理的,这就是理由.

 

选择和挑取

通常一个picklist的内容是由一个对象的状态或数据决定.如果你有一个person对象,你想找出他(她)的配偶,你只能挑选那些注明了已婚的人,他的配偶和他是不同性别.这是一处界面与业务规则有关的例子,不过,人们通常会忽略这也是业务规则,但它的确是.问题在于哪里是业务逻辑,我们能否以这种方式合成我们的系统,而业务逻辑不需要重复编码.

 

让业务对象回叫用户界面.常常很有必要让业务对象来问用户界面一个问题.这是因为业务对象不能预计到用户界面的每一种情形.怎样让业务对象回叫用户界面的确是一个问题.在这儿需要回叫函数让业务对象提示用户一些目前的状态,用户违背了什么样的规则,以及其它一些重要的信息.

 

这儿没有对上面问题的最好回答.你的应用程序必须有一个体系结构,必须能够解决这些问题.构建这样的应用程序结构是比较花时间和金钱的.但是目前显然没有在Delphi环境下商业成品化的软件能解决以上所有的问题.因此做你自己的应用程序框架设计也许是必要的.

 

CGI

由于你始终是通过业务对象的公共接口来对它进行访问的, 很有可能你打算给它提供一个html的前端接口.这个章节有一个这样的例子(在哪里?我没看到--译者)