Caché 快速开发新应用的奥秘

Terry Ragon 总裁 InterSystems 公司

InterSystems鼓励采用一种灵活实用的方式去开发应用系统,而不是严格的依附于某一种流行的开发理论。本文根据我们的经验为大家提供一些建议。然而,需求、看法、风格都是多样化的,我们建议每一个程序员采用一种最好的开发工具。Caché提供了很宽泛的开发方式,不仅仅是在下面推荐的这些。

用对象来开发新的应用

我们强烈推荐大家使用对象方式建立数据库是因为:

对象可以提供一种更丰富的数据结构,更贴近现实生活中的数据。

编程更加简化;开发人员能更加清楚的知道自己在做什么,自己在操作什么。

自定义的类可以简单的替代标准的类,这样就可以更简单的在新的版本中自定义一个应用并提供支持。这个特点对于一些要定制不同版本的人来说是非常重要的。

封装的“黑盒子法”意思是程序员可以改善一个对象的内部功能,而不会影响到其他的应用。

对象提供了一种简单的途径去连接不同的技术和应用。

对象技术可以很自然的匹配JAVA,提供更简单的网络开发和基于GUI的用户界面。
许多新的工具都采取对象技术。

对象可以把用户界面和其他的应用分开。这样,如果要采取一种新的用户界面的技术(可能是网络或者一些现在还不能预见的未来的技术),开发者可以重用大部分代码。

对象对于数据库的对象和有意义的临时对象是非常有用的。通常,对于一些小的临时的存储,使用一个或几个变量或者数组更简单;在实际使用时这样也更实用。

虽然大多数的数据存储是通过对象,但是有时人们也会通过Caché的多维数据引擎更直接的使用global的引用去实现数据的获取及设定而达到更好的效果。在需要访问一些特殊的数据结构的时候,而不需要通过对象或者SQL或者需要更高的运行效率的时候,采用这种方法是很好的。

综合开发过程—— 一个反复的过程

  • 开发的过程往往是一个反复的过程,它包括了:
  • 设计库的类空间,包括属性和方法
  • 写代码
  • 创建用户界面

虽然理论上讲,在编写代码以前能够把所有设计的工作完成是最好的,但是实际上会有设计的纰漏,与客户的实际需求发生分歧,以及一个不能结束的应用过程。因此,InterSystems推荐一种更加反复的开发过程。

尽管我们都注重完整设计的重要性,然而我们也清楚的知道对于一个复杂的应用,真实的设计会随着开发的深入而更加清晰,而一个有用的应用往往需要客户的要求改动的反馈。Caché的一个长处就是开发者可以快速的开发,改动也很容易,很方便地实现新的设计改动和重写一部分代码。人越少开发会进行的越快(归功于Caché开发的多产性),产品也会更贴近于客户的需求。

事实上,Caché的高速开发不仅仅表示项目可以在更少的资源下更快的开发出来,也表示可以利用一些不需要完成的应用。大家都知道,增加开发人员会给开发带来很大的复杂程度,越多的人需要越多的交流和统一意见以及对全局的把握就更少。因此,尽管得到了更多的资源,相比于更少的人开发的话,投入市场的时间会更长,而可靠性也会降低。有时,其结果是项目很难被完成。

InterSystems公司提倡开始于基本的库设计。当它完成的时候,业务和数据库逻辑就可以和用户界面的编程同时进行了。在某些情况下,在写相关用户界面以前先写主要的业务逻辑可以帮助确定需要获取哪些信息。一些人喜欢一开始就写用户界面来确定应用的外观和感觉。这种方法往往只适用于库结构相对小而且简单的小的应用,而对于一些复杂的应用,我们建议还是先从数据库的设计开始。事实上,对象和代码的优化是一个反复的过程。最重要的就是开始。

自由的图示来表示逻辑流的算法和其他的复杂的代码部分通常非常有用。它们可以提高程序的可靠性和可预言性,简化编程,并使设计不同的属性、方法的标识更为容易。而在这些图示刚刚写好还可以被理解的时候,立即去写代码和算法是比较好的。这也是我们推荐反复开发的重要性的一个原因。

我们需要一个建模工具吗

Caché支持很多不同的建模工具,例如被很多组织所喜爱的一个外部设计的工具Rational Software的Rose。这些工具非常好的关注于结构的静态设计,例如数据库的属性,而且使用的时候也非常轻松。
然而,建模工具在使用关系型数据库的时候去把现实生活中丰富的数据结构拆分成由很多复杂的关系连接起来的二维表结构。这种拆分在Caché中是不需要的。

InterSystems并不推荐在Caché上使用建模工具。

我们建议:

  • 直接使用Caché的对象架构来定义主要的类的数据结构(以及一些重要的方法的标识),尤其是主要数据库的类。
  • 然后开始写代码。
  • 在一个反复的过程中,完成余下的设计。
  • 这样做的理由是:
  • 它避免了对现实的对象的设计以及他们的结构的广泛的争论。一些项目失败就失败在开发者在抽象建模的时候花了太多的时间。
  • 通常在代码编写的过程中,方法的代码的特性就会更加清晰。程序员在开发的过程中,需要事先说明一些内容。
  • 采用这种方式,在设计和编写代码的时候只需要一种简单的工具。程序员可以减轻在不同的开发工具之间建立联系的工作。

对于刚接触Caché的人来说,我们特别推荐立即使用这个产品去写一些代码获取一些经验。

尽管这些不是标准的建议,但是我们相信这样会使开发一个较高的应用更加快捷。这种反复的过程使得开发者不断优化代码,而不是拘泥于预先定制的框架,它们会随着开发的进展而过时。这也避免了在实际开发中缺乏经验而一起的麻痹和过多的分析。

Caché中的数据建模

在对象设计的时候,很容易卷入一个对对象性质及其方法的抽象的讨论。除了消耗时间以外,确定的方法通常与应用的实际的功能没有太大的关系。InterSystems相信方法的需求和功能在编程的过程中会变的更加清晰。

很明显,一些基本的设计在编程以前就应该形成。我们推荐使用Caché的对象结构去实现:

  • 什么是主要的数据库类?(例如,发票,厂商,病人)
  • 什么是他们共有的性质?(例如,哪些是其他的对象可以看到的属性,哪些是只有类自己才能访问的属性)
  • 在这些类之间存在什么联系?(例如,一个病人应该有一个“私人医生”的属性,作为一个医生的引用,一张发票和许多列出来的物品有一对多的关系。)

在一个属性被设定的同时,通常需要去设定这个属性的特征(例如,这个属性需要一个值吗?他必须是一个独一无二的值吗?他需要被索引吗?)。这个时候也需要为一些可计算的属性编写代码(例如,“年龄”属性就是在“生日”属性基础上计算出来的。)。

是否要在最初的设计的时候设定方法的名称和特征呢?(特征包括返回值,如果需要的话,有多少个什么类型的传入参数)。开发者希望在最初的设计的时候确定一些明显的和重要的方法的特征,但是大多数的方法需要在编程的过程中确定了他们的功能的时候才能完成。同时,特征经常在随着代码的编写而被改变。通常写一个方法的代码最简单的办法就是在他的特征在确定了的时候来写。

三层架构的三种类型
当人们谈论三层架构的时候,常常会因为下面的三个原因之一而产生混淆:

  • 三层架构的硬件部署-数据服务器、应用服务器、客户端是不同的机器。
  • 三层架构的系统软件的结构-数据库服务,应用服务,客户端,他们不一定要在不同的机器上。
  • 应用软件开发的三层架构-数据库逻辑、业务逻辑、用户界面逻辑,这三层是有严格的区分的。然而他们也不一定要在同样的或者不同的机器上。

Caché拥有三层的系统软件结构,并支持广泛的硬件部署方式。

不需要Caché的开发者认识到部署架构的问题;从一个单机上把所有的东西放到两或三层的结构或者点对点的硬件结构都不会需要重新编译或者重新连接软件的模块。

三层应用软件的开发

从概念上讲,大部分的数据库应用包括下面3中不同的函数类型:

  • 用户界面逻辑 – 这是输入输出命令的代码,例如客户端和服务器端的窗口代码,浏览器代码等等。这些代码决定了信息是怎样被采集和发布的,业务逻辑是怎样根据不同的输入输出事件发出请求的,以及怎样可视化的回复。
  • 业务逻辑- 业务逻辑通常是应用系统的主体代码。他包括了实现业务规则和业务流程的算法代码,这也是一个应用的实际功能。(业务规则的一个例子就是:所有超过$100,000的发票需要2个经理的签字。一个业务流程的例子就是:支付一张发票需要符合一个经授权的购买流程,验证货物和需必需的证明文件都已经收到,然后才打印发票。)
  • 数据库逻辑- 从硬盘上存储和检索数据,查询数据库里的数据,维护数据库的完整性等等。例如,在关系型数据库里,填写一张发票需要更新很多的记录(采用对象技术会简单很多)以及很多的状态位。

在最近几年,坚持采用这三层结构来开发数据库应用的规则是一直被很高的推崇的。在那样的模式里,某一层该如何调用其他层的代码是严格规定的,经常会把一些类的名称而不是功能定义在一些层里,而只是对其他层的对象的镜像。例如,可能存在一个业务逻辑类Invoice_bl的一个save方法只是简单的调用了数据库里的一个类Invoice_db的叫save的方法去实现这个操作。

三层结构开发的本质是把开发分为不同的层面有利于大规模的开发团队的分工合作。

你适合三层结构的应用软件开发吗?
Caché可以支持三层结构的应用软件开发。然而,我们并不推荐这样做。我们建议:

  • 集成业务逻辑和数据库逻辑层
  • 把用户界面和业务/数据层分离
  • 保持用户界面层越少越好,把越多的代码放在业务/数据层越好。

这里是我们的建议的基本原理:
在三层应用开发的结构中需要业务逻辑层的开发者有丰富的数据库编程经验。但是使用Caché的情况就不一样,Caché提供了可以实现自动的存取信息的智能的对象和能够把大量的数据库查询放在程序中的查询向导,而自动实现了许多数据库的基本功能。同时,多维的数据模式使得不需要把丰富的对象分解成为关系型的表,所以Caché编程更为简单。

因而在Caché里面很少的数据库逻辑需要程序员去编写,就消除了对数据库专家编程员团队的需要。他也使得数据库的对象更加真实地反映功能强大的对象模型;两个发票对象(一个在业务逻辑层一个在数据库层)将被一个压缩在同一个层面的发票对象而替代。这样的简单的模式可以加快开发速度,减少代码量,减少未来的维护量。

然而,我们推荐在一个分离的用户界面尽量减少代码量的原因是:

  • 以后再编写新的用户界面更加简单。
  • 把核心编程员和界面编写者很好地严格的区分责任。
  • 在用户界面层的类不会和业务逻辑层的类紧密的粘合在一起。
  • 另一个把用户界面的代码减少的理由是:用户界面里面的代码的安装和升级会带来大量的系统管理的负担,而通过Caché应用服务器管理的在业务逻辑层的代码的安装和升级的工作量会小很多。

Caché数据库的独立性

数据库的独立性在Caché里面通过使用Caché对象储存得到了很好的促进。当定义一个数据库类的时候,一个程序员需要指定存储的类。这个存储的类决定是直接存在Caché多维数据库里面还是存进一个关系型数据库。把一个应用转移到一个关系型数据库里面,程序员只需要指定不同的存储类就可以了(完成这个工作的简单程度相当于给应用修改一个单独的逻辑名称),然后重新编译。

编写业务和数据库逻辑

在Caché对象架构中,Caché的对象类可以被建立、修改、编译。
Caché拥有智能对象,所以开发者不需要写方法去调用、保存、删除对象。Caché在编译类的时候自动就生成了这些方法了。(在某些情况下,开发者希望去编写一些自定义的数据库方法,他们也可以这么做。)

Caché对象语言是一个为数据库应用编写业务和数据库逻辑的非常优秀的语言,所以InterSystems公司强烈推荐使用COS(Caché对象语言)。他提供了比其他的语言更为快速的应用开发,他和Caché数据库的多维数据的紧密联系可以使得数据库应用的更好的表现。他和Caché数据库的多维数据的紧密联系也可以使得在运行中的系统上管理系统、改变配置以及更改代码更为简单。

然而,他不是唯一的选择。Caché对象服务器可以把Caché对象封装为ActiveX, Java, C++, 或者 CORBA的对象,这样有利于一些熟悉Visual Basic, Java,或者C++的程序员的使用。

Caché也可以通过ODBC或者JDBC提供数据库服务,允许一些基于SQL的开发。

建立用户界面

用户界面的代码通常使用Visual Basic, Delphi, C++, Java或者HTML来编写。许多编程员都表示采用基于网络的HTML开发用户界面是最快的,而使用C++开发的用户界面会比其他的开发工具消耗更长的时间。
通过Caché的对象服务器,它可以和其他的开发工具相媲美。HTML的代码可以直接被嵌在Caché对象语言里面。

Caché Server Pages专门针对那些喜欢建立网页界面的程序员,它可以把Caché代码和其他的网页开发的通用件工具开发一起使用。

对于程序员来说,决定编写用户界面的技术的主要因素是选择一个技术他们熟悉的或者非常容易被学习和使用。使用多层复杂的技术很容易在用户界面层把技术复杂化。

网络或者C/S界面?

最困难的决定之一就是选择采用B/S界面还是采用C/S界面。

我们的客户的经验表明如果你有一个现有的可以在Caché上面运行的基于终端的系统,到目前为止,最快捷的办法就是使用Caché Server Pages和嵌入的HTML增加一个现代的用户界面使得他可以支持网络。其结果往往是保留了大部分的原代码。在某些方面,就像把一个哑终端替换成一个智能而且复杂的终端。这个方法通常可以带来基于浏览器的面向应用的程序。然而,通常他不是真实的复杂也不像一个事件驱动的C/S界面的应用系统给用户那么多的管理。

在编写一个完整的新应用的时候,最关键的就是在用户界面层和业务/数据库层之间保持一个严格的界限,以及使得用户层越薄越好。就像大多数时候,B/S和C/S结构都是被最终要求的。总的来说,一个基于网络的用户界面往往开发的比较快,而面向浏览器的应用也会有更多的优点也可以被更广泛的访问。强调网络符合广泛的市场的主题,而C/S的界面看上去更加完善。

部署和维护一个应用

硬件平台和操作系统
Caché应用系统可以不变地在不同的硬件平台和操作系统上运行,包括了Windows 95/98 和NT等, 所有的主要 UNIX 平台, OpenVMS, 和 Linux.

硬件配置
一个Caché的应用可以实施在一层、两层、三层或者点对点的硬件配置上,而不需要重写代码或者重新编译。在非常庞大的系统中,可以有多个Caché的应用服务器和Caché的数据服务器。
通常一个客户只连接到一个Caché应用服务器。而连接到准确的数据库服务器是这个应用服务器的责任。

总的来说,一个应用服务访问在他所在的同一台机器上的数据服务会减少很多的开销,所以除非真的很有必要把数据服务和应用服务分布在不同的机器上,InterSystems公司建议把他们放在同一台机器上。
安装一个应用系统和在一个正在运行的系统上引入一些改变

一旦一个应用被写完,他就需要被安装和进一步修改的。对于上千台电脑和许多的服务器来说,大多数的技术都把这作为一个比较棘手的问题。

Caché简化了一个应用软件的安装。Caché对象语言的代码只需要装在一个单独的数据服务器,其他的电脑可以通过DCP或者ECP得到代码的复件然后缓冲他们。

要在一个运行的系统中改变一个Caché对象语言的函数,简单地把改变好的源代码读到放置那段代码的单一的数据服务器上就可以了。源代码会被自动编译,而应用系统也会被告知需要重新读取修订后的函数。当然,这些改变需要提出一个警告;一个进程从旧的版本的系统发出一个指令到另一个函数中企图返回改变后的函数的时候,会产生错误。