【IT168 业界评论】
实现机关办公自动化工作需要计算机技术的支持，在计算机软件范围中，有网络操作系统软件、数据库软件和开发工具等基本系统软件，在此基础上开发出适合本单位使用的应用软件。对如何选用系统软件，笔者没有发言权，但是根据实际情况，笔者有必要对Lotus Domino谈点人个看法。因为该软件一是目前比软流行且已为众多机关所采用，二是该软件费用软高，三是由于该软件是个半成品软件，稍加改动就可以适用于给领导演示。可以说，该软件有许多优点，但笔者在咨询有关专家后，认为由于 Domino 的技术限制和我国政务办公信息系统的特殊性，选择 Domino 作为我国政务办公信息系统的基础平台，复杂功能实现困难、使用麻烦、开发费昂贵、互操作性差、界面呆板、数据共享与集成性能差，系统固有各种缺点远大于其优点，在部委系统内完整的成功案例很少。该软件不适合于部级以上党政军机关应用，其原因主要有以下几个方面：
点评：这里发现该文作者存在一个问题，即一方面认为Notes/Domino是一个半成品软件，可以迅速开发，同时又将这种迅速开发原型与那些经过需要较长开发时间的技术相比较，指出其种种缺点，这是不公平的。
事实上，Notes/Domino系统开发一直存在两种方式即简单开发和系统化定制。
简单开发--使用Notes/Domino提供的设计元素、甚至模板数据库直接堆砌而成，以基本功能实现为主要目标，其优点是对开发者要求低（甚至许多EndUser都可以进行），开发周期短、费用低，缺点是对界面和复杂应用考虑较少，不能满足用户的特殊要求，属于较低层次的开发。
系统化定制-充分考虑到用户的特殊需求，以Domino为基本设计平台，结合多种先进技术和应用软件，集成多种后台数据类型的增值性开发。这种开发，可实现的功能更多、界面更美观、也更能贴切用户的需要，但相对的，周期较长，技术门槛较高，开发费用也较高。但考虑到可以充分发挥Domino强大的功能，还是值得的。
两种开发方式互有补充，各有优缺点，所以泛泛的批评Notes/Domino开发的“各种固有缺点”有误导之嫌 。
1．速度太慢。 Domino 是基于文档的数据库、不具备数据快速检索功能。当数据库中文档数超过二到三万条时，几乎显得无能为力。Domino 使用解释性的客户响应机制，在采用 Browser-Domino 结构响应 Web 请求时， Server 端实时地将 Domino视图转换或解释为 HTML 文档传送回客户端，对于复杂视图转换时间长。在客户端 Browser 上利用 Java Applet 实现数据的互操作性，客户端启动 Java VM就需要耗费很长时间， Java VM 启动后，还要解释运行缓慢的Java Applet，用户等时太严重。在 PIII500 PC 服务器上对 1 万个文档的数据库目录列表就需等待 1 分 20 秒左右，超出一般用户的可忍受程度。如在10 M 共享网络上，10 个用户同时查询具有1 万个文档的数据库，将费时数分钟，而一般部委内部网络上均有数百个用户。
点评：这里发现其论据有问题，将检索速度与某个条件下的显示速度混为了一谈，事实上，由于要求下载时间等原因，java applet本身就存在着初始显示慢等问题。而Domino中的Java Applet作为为用户提供的一种易用的快速开发元素，确实也存在一些不尽人意的地方，例如没有分页功能，这意味着所有的数据都要一次读到客户端-这直接导致了作者所提到的显示缓慢问题。以此来指责Domino的检索速度是没有说服力的。关于检索速度，相信我做过的一个实验更能说明问题，我们曾经在一台PIII500 PC机上建立过一个十万条文档的测试数据库（每个文档有20个域，每个域填充由乱数产生的单词，单词的数目也是由乱数决定（不超过20））。在这个数据库中检索包含某一个单词的文档，平均耗时约为0.1秒。附带提一句，Java Applet并不是显示视图的唯一选择，Domino本身还内置了ht ml的显示形式，只需要修改一下视图的属性，不需要任何代码，其显示速度非常快。如果对这两者都不满意，还可以进行定制开发。由于篇幅和主题的问题，这里就不详述了。
2． 综合统计能力太差。在办公信息系统中,实时地对公文运行状况进行分类汇总、监控是必不可少的功能。而 Domino 是基于文档的小型数据库，如要求进行多维数据汇总，其实现过程十分复杂，效率极其低下，反应缓慢，远不如关系型数据库。
点评：“Domino是基于文档的小型数据库”，“基于文档”可以说不错，“小型数据库”的印象却不知从何得来？不知该文作者的标准是什么？十万篇文档和十万条关系型记录，无论从存储容量、检索难度、复杂度等方面都不可同日而语。所以，在我的印象当中，Domino数据库的指标一般只提容量，很少提文档数目，没有什么原因，只是因为在达到文档数目的限制前存储介质早就“爆”掉了。并且将Domino简单地称为“数据库”，对于它所能完成的工作而言，实在是一种误解，Notes/Domino一直是作为市场领先的服务器电子邮件和群件产品而得到广泛承认的。至于“对公文运行进行分类汇总、监控”，以我们的经验来看，没有问题呀，甚至可以说是强项。至于“多维数据汇总”，“远不如关系型数据库”，这的确是事实，不过该文作者似乎把办公信息系统的任务与管理信息系统（MIS）混淆了，这是一个普遍存在的误区。对大量的原始数据进行多维汇总、处理加工、产生统计报表（原始文档），这些是MIS系统的领域与专长。而运用工作流机制、协同、通信、促进知识共享、进度、效率和生产率才应是办公信息系统的着重所在。从国内办公系统的现状来看，正是这些普遍存在的误解，导致了国内办公系统的开发复杂、投入多、收益少。
3．实现复杂的应用和界面困难。政务信息系统的面界一般具有众多的界面元素。如会签界面上至少有文件标题、正文、附件、起草人、起草时间、处室审核人、审核时间、司局审核人、签发人、签发时间、会签司局………等等数十项，在 Domino 的视图上实现如此众多的界面元素十分困难，在 Domino R5 版本中，对于复杂视图在 Notes 中有时竟然无法正常显示而导致死机，而采用 Browser 方式需将复杂视图在服务器端转换成 HTML + Java Applet 传送到客户端运行，耗时太多，运行缓慢。
点评：这些更不知道从何说起了，就我所知，利用Domino想要实现该文作者提到的政务系统无论从界面还是功能，都应该是很成熟的技术了，一点也不困难。事实上，困难的应该是这种想把这数十项元素放置到同一个视图的想法，利用这样一个视图来处理公文，这既不现实也不实用。这里又提到了Java Applet，由于上面已经说过，不再驳了，建议他使用html方式，或者干脆自己定制一个界面好了。至于死机问题，确实存在，不过主要是在开发端和notes客户端（Domino Server的稳定不成问题），或许是因为Notes R5在界面上改进了很多的原因吧，R5(尤其是R5.0和R5.01)的客户端和开发端稳定性差了很多,R5.05就已经好多了，希望Lotus公司能够尽快改进这些问题。
4．界面呆板。Domino 的界面主要由帧、视图、大纲等一些固定格式组成，缺乏灵活性，样式粗糙呆板，与 HTML 或应用程序界面相比过于原始化、简单化，缺乏个性和艺术性。
点评：的确，直接使用这些元素是缺乏灵活性，但原因恰恰来在于这些设计元素易用性。一个粗通Notes编程的人可以在极短的时间内搭接出一个基本可用的系统，这是其它系统所难实现的。随着对于Domino编程的进一步了解,还可以进行界面的定制，应用诸如内嵌HTML代码、结合Javascript、DHTML等技术开发出开发出充满个性和艺术性的界面的应用程序，这方面，国内已经有成功的例子，建议在今年的Domino Day可以好好看一看。当然，灵活性的提高通常也伴随着复杂度的提高，这些工作都是需要一定的编程量的，如何取舍，是见仁见智的问题。
5. 数据共享、导入、导出限难。Domino 文档数据库不支持ACCESS, EXCELL,Fox Pro等通用前台数据库的共享访问，也不支持各种 SQL 检索工具通过 ODBC 访问，不支持 SQL 语句查询，数据共享性能极差、数据批量格式化导入导出困难，在流行的 Internet/Intranet环境下，难以满足用户端数据访问多样化的需求。
点评：首先注意到该文作者提到的都是Microsoft产品，所以这里特别提一下Domino R5可提供与Microsoft Office大量的集成。用户可以在www.lotus.com/itcentral网站上找到系列白皮书及文章。附带提一下Domino R5.05中包含有几个新的Microsoft集成功能，包括：
· Domino Network File Store，它允许通过Windows 网络访问任何Domino数据库并把Domino数据库转换成网络文件共享数据库。
· iNotes Access for Microsoft Outlook，允许用Outlook 98/2000客户端访问Domino邮箱中的邮件/日历服务。
· Domino Collaboration Objects，新增功能，优化Domino使用COM的开发。
· OLE/DB连接器，用于Domino与SQL Server 7之间的内在数据移动。
其次，由于把后端数据合并到事务处理中可以最大限度地体现 Notes/Domino 应用程序的价值，所以Lotus公司非常重视，提供了一系列的产品或接口（LSX、DECS、LEI、ESB、NotesSql、JDBC等）。利用这些企业集成技术，可以将那些在传统意义上很难访问的数据集成到事务应用程序中，因此完全可以满足数据访问多样化的需求。
