资深程序员点评当前某些对Lotus Domino 的不实评论
（注：下划线部分是原文。）
实现机关办公自动化工作需要计算机技术的支持，在计算机软件范围中，有网络操作系统软件、数据库软件和开发工具等基本系统软件，在此基础上开发出适合本单位使用的应用软件。对如何选用系统软件，笔者没有发言权，但是根据实际情况，笔者有必要对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等）。利用这些企业集成技术，可以将那些在传统意义上很难访问的数据集成到事务应用程序中，因此完全可以满足数据访问多样化的需求。
下面简单介绍几种企业数据集成互连方法。
1．@DB 命令--可以使用 @DB 命令同使用 ODBC 的关系数据库交换数据。
2．DECS - Domino 企业连接服务 基于表单的开发工具。提供对企业数据和应用程序（包括关系数据库、事务系统以及企业资源规划(ERP) 系统）的实时存取。
3．LS:DO - LotusScript Data Object---可以存取任何 ODBC 兼容的数据源的 LotusScript。
4．JDBC - Java Database Connectivity---通过标准 JDBC 类从 Java 代理到关系数据的访问。Domino 还附带 JDBC 到 ODBC 的桥梁。
5．Lotus Domino Connector LotusScript Classes---拥有一致界面编程访问企业数据和应用程序的一种统一的对象模型，可以通过 LotusScript 或 Java 使用这些类。
6．Lotus Domino Connector---提供到企业数据源本地连接的模块。通过 Domino 企业连接服务或利用 Domino 类编程可以访问这些连接器。Domino 服务器提供了对 DB2、Oracle、Sybase、基于文本和文件的系统、EDA/SQL 和 ODBC 的连接器。另外，还可以单独获得到 ERP 应用程序、事务监视以及目录系统的额外连接器。
7．LSX - LotusScript 扩展---创建工作于 Domino 应用程序、Java 和 OLE 中的定制对象。MQSeries、SAP、DB2 和 Rich text 都是 LSX 的应用范例。
8．Lotus Enterprise Integrator---提供支持事件驱动或定时大量数据传输以及数据源同步的数据分布服务器。
9．Domino Connector Toolkit---为开发者提供构建其他 Domino 连接器和用于 Java 或 LotusScript 类的工具和信息。
需要指出，这些方法大部分不需要额外的购买（LEI与ESB除外）。
另外，文中提到不支持“各种 SQL 检索工具通过 ODBC 访问，不支持sql语句查询”，显然，作者的思路还局限在关系型数据库开发的思路中，忽视了对于办公系统的主要处理对象-文档，这种查询是否还适用。比较而言，Notes/Domino提供的强大的全文检索功能要更实用一些，决不是仅仅查询一下标题和关键字这么简单，其效率也更高。别忘了，类似的全文检索功能，大多都是需要单独购买的，而Domino则是内置的。另外提一句，使用sql通过 ODBC 访问 Domino 数据的 NotesSQL 驱动程序可以在 Lotus Web 站点 http://www.lotus.com/ 免费得到。
对于数据的共享，下面在关于“可扩展性”问题里还会提到数据扩展的问题
6．成本太高。使用 Notes-Domino 构筑办公平台在成本上与基于 ASP-SQL 或其他当前通用解决方案相比，其成本不在同一数量级，有可能高出数倍乃至数十倍。
点评：比较成本，前提应是功能相似，因此，一般的比较是Domino与以Exchange Server为邮件平台的办公系统。
Domino系统内置了办公系统所需的电子邮件、群组协作、工作流、角色控制、安全机制、复制机制等功能等，若以ASP-SQL模式实现，在成本中势必要加上Exchange Server。
既然提到了ASP-SQL办公系统方案，请参考一下微软最近宣布的Exchange 2000的定价。可以看到当某个产品成熟时，微软一般会提高其价格。因此Exchange 2000的价格大大高出Exchange 5、6，当然还包括Domino R5。当向Zdnet提及Exchange价格变化时，微软的服务器应用群件产品经理Stan Sorensen谈到："我们的价格比其它产品都高"。现在，Exchange用户从Windows NT 4.0、Exchange 5.5以及Windows NT 4.0向Windows 2000和Exchange 2000升级时面对着不可思议的高成本。这里强调指出，Exchange 2000与Domino是相似、但绝非相同的产品。Domino可以提供超过Exchange的附加特性和优势。例如，Creative Network研究表明：Domino用户平均可在一个单独的基础设施上享用347个协作应用，比典型的Exchange用户（仅37个应用）多十倍。还有一点可进一步说明产品功能的差异，那就是微软已宣布一个新产品 - "Tahoe"，此产品试图弥补Exch ange的不足，使其成为"办公室用户可以简便获取、共享与发布信息的服务器"。
据此，我完全得出了相反的结论。
7．硬件要求高，带宽需求大。Domino 是一种传统的Clent/Server平台，尽管为适应Internet环境进行了更新，但其核心技术依然源于过时的Clent/Server方式。在多用户的Client/Server环境下，采用 Notes-Domino 解决方案，对服务器的性能要求大大高于ASP-SQL 等先进的 Browser/Server 解决方案，前者对网络带宽的要求同样也很高。
当前，在应用中选择C/S结构还是B/S结构是讨论较多的话题。B/S结构的特点在于具有广泛的信息发布能力，客户端只需要普通的浏览器即可，特别适合简单的应用流程和Internet应用，由于其简单、轻量、易于维护，因此受到了最终用户的欢迎。但在大型复杂应用中，由于在B/S结构中有一些根本的弱点，使B/S结构的性能仍不能与C/S结构抗衡。采用B/S结构，客户端只完成浏览、查询、数据输入等简单功能，而绝大部分工作由服务器承担，因此服务器的负担重，对其性能的要求更高！而采用C/S结构时，客户端和服务器端都需要处理部分任务，对客户机的要求较高，但因此反而减轻的服务器的压力。B/S结构应用的是HTTP协议，由于HTTP固有的局限性（最早为单纯网上浏览而发展起来的），因此B/S结构不适合复杂的交互式应用。而C/S结构一直在交互式应用中大显身手，技术成熟，稳定，对复杂应用适应性好。例如，在完成一次任务处理的交互过程中，C/S结构只需连接一次，而B/S结构需要对任务中的每一个请求都重新进行连接，其效率大大低于C/S结构。现在，随着客户计算机的计算能力的不断增强，越来越多的关键性应用又重新选择了C/S结构。所以，B/S方式和C/S方式各有优缺点，可以互补，怎么能说C/S结构已经过时了呢？（乌鸦的补充：在我转贴这篇文章的时候，市面上基于Domino平台实现的B/S结构系统已经比比皆是，极尽奇巧之能，所以这点也不能成立啦。）
8．可扩展性差。 Domino 与其他程序的用户接口实现困难，致使程序扩展性能差，不利于与各类输入输出设备（如扫描仪、IC密码机、打印机等）实现无缝链结，以及与其他程序有机整合，难以做到办公信息系统的文档一体化。(VB、C API、C++、Java)
点评：对于第三方软件的整合和软件的扩展是软件一个必要重要的工作，也是需要软件开发人员考虑并做工作的地方。下面谈一谈Domino应用的扩展和整合：
1)基于数据的扩展
首先，前面提到过Domino提供了LSX、DECS、ODBC、JDBC等多种方法来存取外部的数据，利用这些方法，Domino应用可以存取外部的数据，达到数据的一致和同步，从而将应用整合在一起。举例而言，我们曾经通过这些方法，利用Notes强大的文档管理功能来管理并检索通过下载软件得到的数据，大大提高了这些数据的使用效率。
第二，Domino对XML提供了很好的支持。XML的应用已然成为软件开发的一大趋势，越来越多多软件开发将使用XML作为软件的数据接口。在这种情况下，Notes应用和其他软件之间的数据交换之间将更加便利。
第三，Domino R5开始使用了一种名为CORBRA的架构。这是一个由OMG定义的开发标准。在分部的计算环境中，CORBA作为中间件，为客户端调用驻留在其他计算机上的远程编程接口进行服务。CORBA使用IIOP协议，这个架构将提供分布式对象见相互定位和交换数据的传输功能，提供异种语言、操作系统、硬件平台、网络互操作性；从而式分布式系统的设计、实现都大为简化。从软件发展的趋势来看，很多应用软件的设计开发将遵循这个架构，提供相应接口。在这种情况下，Notes应用和其他应用软件的集成将更加容易。
2)开发工具的扩展
Notes开发本身使用公式、Lotus Script和Java。
a. LotusScript是一种类Basic语言，可以调用各种对象、API。完全可以像VB一样实现对各种ActiveX控件或对象的操作，例如将视图直接生成Excel表格或着存取Access数据库数据，还可以通过操作或者代理调用外部的其他程序扩展自身功能。
b.可以将其他应用程序提供等动态链接库等，在Notes中声明其接口以后直接调用。
我们的产品Indi.Image（乌鸦的话：看来这位前辈是来自慧点科技的吧？据我所知，就是慧点老是用Indi.xxx的名字，不知道到底是什么意思？）就利用了这种方法，使软件可以无缝地使用各种扫描仪，包括高速扫描仪，将各种资料扫描，并转换成高效的格式存储在Notes数据库中，统一进行管理，包括对不同的扫描资料进行各种有机的组合。
c.利用Lotus提供的API、控件和对象
Lotus为Notes应用的扩展提供了很多API－－C API,HiTest API, C++ API。这些API是用户可以很自如的从外部直接控制Notes数据库的各种对象，包括数据对象、设计对象、事件对象，从域对象到数据库对象。利用API开发，可以很好地将其他各种应用程序和Notes应用结合起来。
我们就曾利用这种方式和保密机构进行合作，在Notes应用中无缝集成了对方的加密系统，使既其保持了Notes应用原有的使用简便性，又达到了用户对安全保密的要求。
VB、VBA中也可以调用Lotus对象。在安装过Notes客户端的系统中，可以通过Notes对象，独立于Notes界面访问数据库、发邮件，并使用标准的网格显示视图等。还可以通过在服务器端自定义的接口来实现客户端程序对Domino数据库的访问。
事实上，甚至还可以通过Vbscipt写的ASP页面访问Domino数据库，实现发邮件和查看日历等。
3)操作系统、硬件平台的可移植性
在软件扩展方面，Domino应用还具有良好的可移植性。Notes应用是基于Domino平台来开发使用的，而不是直接基于操作系统。所以Notes应用在不同硬件平台、不同操作系统之间的移植性能很好。
9．不符合中国国情。我国政府机关政务办公信息系统不适合使用基于文档型的数据库平台。Domino 适用于小型简单办公系统，如中小企业、中小学校、中小机关。一般为某人起草一个文件、传给某主管上司批示、办结这一简单流程，特别适用于西方简捷办公模式，办公文档也没有太多的字段，一般情况下仅有文件标题、正文，起草人，批示人等十个左右的界面元素。而我国政务办公系统中的文档，每一个正文往往附带数十个附加字段，如一个普通的司局会签文件就有文件标题、正文、附件、起草人、起草时间、处室审核人、会签司局、会签人及时间、等等数十项，关系复杂、流程分散、牵涉面广，简单文档数据库难以承担, 更适合使用关系型数据库。因此使用 Domino 开发我国政务信息系统不适合中国国情。
点评：立论很奇怪！关系复杂、流程分散、牵涉面广，正是内置工作流和安全机制的Domino系统的用武之地呀！（再强调一下，Domino不是“简单文档数据库”!）至于“数十个附加字段”，更是Domino的拿手好戏，反而是该文作者推崇的关系型数据库，在这方面很难施展。相信有大型关系型数据库开发经验的人都知道，关系型数据库对于数据类型、长度、数据关联都有很严格的要求，而且对于数据结构的修改更是慎而又慎，哪怕是一个char类型字段长度的修改，都是令开发者很挠头的事情，这样怎么能适应政务信息系统的开发呢？事实上，西方的办公模式确实简洁，重实效而轻形式，但并非简单，尤其是大型的跨国企业，往往数百家机构分布在数十个国家或地区里，普通的软件根本无法适应其办公通讯的需要，而这些大型的公司或机构往往都采用Domino作为其办公系统的平台，这恰恰说明了问题。 （乌鸦的话：当初我看到这个结论也觉得很奇怪，字段多Domino又不会干涉你，而且还可以在程序中自动添加字段。关系分散、流程复杂不正是Domino工作流的拿手好戏吗？呵呵。）
小结：Domino作为一个相对成熟的开发平台，有其长处，也有其不足，不过就其在办公系统领域的表现而言，目前，还无出其右。
本文地址：http://com.8s8s.com/it/it26415.htm