資深程式設計師點評某些對Lotus Domin的不實評論
實現機關辦公自動化工作需要計算機技術的支援,在計算機軟體範圍中,有網路作業系統軟體、資料庫軟體和開發工具等基本系統軟體,在此基礎上開發出適合本單位使用的應用軟體。對如何選用系統軟體,筆者沒有發言權,但是根據實際情況,筆者有必要對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等)。利用這些企業整合技術,可以將那些在傳統意義上很難訪問的資料整合到事務應用程式中,因此完全可以滿足資料訪問多樣化的需求。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14751907/viewspace-408790/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [轉載]資深程式設計師點評當前某些對Lotus Domino 的不實評論程式設計師
- 差異程式設計師-評《程式設計感悟》程式設計師
- 京東資深架構師程式碼評審歪詩架構
- 《程式設計師健康指南》書評程式設計師
- 資料庫設計——評論回覆功能資料庫
- 某公司程式設計師薪資一萬,而“程式設計師鼓勵師”月薪兩萬,網友評論炸鍋了程式設計師
- 巢狀評論的資料庫表設計巢狀資料庫
- 程式設計實踐(評註版) 評註者序程式設計
- 女生節的一個分號,引發程式設計師的瘋狂評論程式設計師
- 【外刊IT評論】Web程式設計是函數語言程式設計Web程式設計函數
- 對程式設計師說點實在話程式設計師
- 評論模組 – 後端資料庫設計及功能實現後端資料庫
- 評論模組 - 後端資料庫設計及功能實現後端資料庫
- 【蓋樓貼】評論中說說你心中的頭號程式設計師大神程式設計師
- 程式設計師的專業主義精神——評《程式設計師的職業素養》程式設計師
- 好書妙評之《程式設計師的數學》程式設計師
- 對其他團隊的評論
- 美團點評廣告實時索引的設計與實現索引
- 一名資深程式設計師的自白!程式設計師
- 好與壞的程式設計師:如何評價程式設計師的水平才算客觀?程式設計師
- 工作滿意度評估程式設計師版程式設計師
- 淘寶商品評論介面,商品評論內容,天貓商品評論介面程式碼展示
- 程式設計師被懟!HR:對不起,我們不招“精通Excel”的程式設計師程式設計師Excel
- 淘寶商品評論資料介面,電商平臺評論介面,行業商品評論資料介面程式碼封裝教程行業封裝
- 程式設計師升職最快的原因竟然程式碼寫的最爛?網友評論:沒毛病!程式設計師
- 教你怎麼客觀評價程式設計師的水平?程式設計師
- 微信小程式--仿朋友圈Pro(內容釋出、點贊、評論、回覆評論)微信小程式
- 京東商品評論資料介面,電商平臺評論介面,行業商品評論資料介面程式碼封裝教程行業封裝
- .Net設計經驗(轉自評論)
- 簡評《實用Common Lisp程式設計》Lisp程式設計
- 《實用Common Lisp程式設計》書評Lisp程式設計
- 評“馬無夜草不肥:程式設計師做業餘專案的重要性”程式設計師
- 好書妙評之《卓越程式設計師密碼》程式設計師密碼
- 使用者評論程式碼實現
- Facebook設計團隊是如何開設計評論會的
- 程式設計師盤點!AI躋身2019年最賺錢職業榜首!評論炸了!程式設計師AI
- 看80萬程式設計師評論:可不可以用中文寫程式碼程式設計師
- 3 條 sql 是實現知乎評論,7 條 sql 實現點贊 + 評論,且可擴充套件SQL套件