深度探討 Delphi 三層架構

　　　　　　　　　　　　　　深度探討 Delphi 三層架構

Andy Kao

前言‧

　　近年來的科技實力，如果不把軟體開發在Web上或使用三層技術，基本上已經是落伍了，因為開發一套應用軟體是一個風險很高、時程冗長的一件大事，尤其是企業的ERP或e化系統，更必須依賴廉價的internet資源，來取得更快速更集中的資訊管理，因此，三層技術對軟件公司或企業MIS部門而言，已經是勢在必行的趨勢。

市場上常用的Web技術基本上分為下列三種：

1.	Thin-Client：就是完全以Web Page為主的Client，一般會以Java/PHP/ASP的語言來開發，當然最新ASP .NET也是屬於Thin-Client的網頁應用技術，顧名思義，用戶端程式較主從架構輕薄短小許多，僅包含使用者介面及基本的驗證程式碼，大部分的商業邏輯程式都在伺服器端，用戶端僅顯示伺服器處理後的結果，沒有部署的問題，更讓應用程式透過網際網路的傳播，可以服務更廣泛的人群，一般都是應用在大眾客戶的系統上，如網站及B2C或B2B 的系統上。
2.	Thick-Client：就是在Client端安裝一些就厚重的基本Windows U/I程式，一般會以ActiveX或ActiveX From或VB/C++/Delphi語言所開發的2-Tier/3-Tier程式，因使Windows的操作界面，所以可以提供良好且親和的U/I，但是Client不僅部署麻煩，更有常見的DLL Hell問題，就是系統會因為DLL版本的不同而容易發生衝突。
3.	Smart-Client：就是利用Client端的U/I優勢，並具有Client端的運算能力，但商業運算邏輯還是利用Web service的方式，並可以支援連線、離線存取功能，最重要的是能自動安裝與更新版本，微軟的.NET平台中，除了上述ASP.NET的Thin-Client方案外，其.Net Windows Form就是標榜Smart-Client為重點，也是下一代企業內部系統的發展主流。

　　從以上我們得知，Thick Client的缺點就是執行程式體積大、部屬不易，與DLL Hell，而Thin Client 的缺點就是必須有網路才能存取、較差的使用者操作、開發方式複雜(例如現今的Web程式)等，因此，Smart-Client希望避免以上缺點，並融合這兩者優點，同時提供親和豐富的U/I、又能集中管理程式，容易部署與安裝，降低管理成本等，為此，市場上出現了一套類似.Net Smart-Client方式的3-Tier開發工具(EEP)，同樣可以達到Smart-Client功能 (除了支援PDA設備以外)，筆者並不強調這方面的高深技術能力，反而是平實的技術的角度來探討如何來達到Smart-Client的效果。

從Delphi三層談起

　　我們都知道，Delphi 4開始就提供三層的開發技術，但一直到Delphi 5才將三層技術成熟化，為此，EEP是利用Delphi 5與C++來完成這兩項工具的開發，所以繼承了所有Delphi 5或7的所有三層優點，在Delphi 5/7中，你也可以輕易使用TRemoteDataModule貼上TQuery與TDataSetProvider，這樣就可以透過MIDAS架構(Delphi的三層中介軟件)在Client端的應用程式使用TClientDataSet來連接，其實這並不是難事，但是，如果如果你要將系統做成Smart-Client那樣，就必須考量下列一些事，如下：

1.	TRemoteDataModule只能有一個：在Delphi中，遠端的主機是由socketsrv與TRemoteDataModule構成的，也就是以微軟DCOM的技術可以將遠端的TRemoteDataModule打開，但是因為TRemoteDataModule對單一Client用戶只能有一個，所以你必須將遠端所有TDataSetProvider與TQuery貼在這個TRemoteDataModule上，這樣整個系統就變得很難維護，如果有多人開發，如何共同維護一個TRemoteDataModule中的Object呢?而且貼了一堆Control，確實會讓人眼花撩亂。
2.	連線的管理，在Delphi中有一個TDataSetProvider必須與TClientDataSet保持密切的連繫，如果同時有多少User使用，它也必須保持TDatabase多少User的Connection，而且一但斷線，很難再重新連線，因此，你可能必須為他開發Connection Pooling的機制，這部份要做到穩定確實須要20到30個案才能達到。
3.	資料Insert/Delete/Update方式：在TDataSetProvider中雖有提供方式讓程式人員可以方便設計，但還是需要人工修正與優化的處理(因為其SQL語句過於呆板與冗長)。
4.	當非常多人連線時，必須要有多個Server的負載平衡(Load Balance)設計Delphi雖有TSimpleObjectBroker元件，但面臨TDataSetProvider的有狀態連線，是無法讓你即時動態更換Server，再加上Delphi並沒有針對TSimpleObjectBroker提出相關詳細說明文件，更沒有看到應用的實例。
5.	這種Server Service的三層架構，應該要能做到同一部Server但能服務不同的客戶或資料庫(例如Application Service Provider的伺服器)，也就是同一個應用程式可以隨不同的Client存取相對的Database，因為你的TRemoteDataModule中的TDatabase是事先寫死的，無法依不同的Client來連到不同的Database主機。
6.	BPL模組的切割，這是發展應用軟體重要的觀念，因為你不可能將一個大系統都寫成一個個EXE，除了程式很大外，更新與異動也很麻煩，所以，你必須在Client寫一個BPL Loader，在Server上設計一個Server控制中心(即所謂的A/P Server)，並將你的U/I與Report寫成一個個的BPL，讓你容易部署這些程式，尤其是必須考量系統上線過程中，還可以機動更換這些Server端BPL，這也是一項挑戰。
7.	對於一個Server Service而言，必須要能隨時加入這些伺服端的服務(即所謂的Server Method)，這部份必須要自行以DCOM來實做Interface，由於Interface的次序是不能隨意調動與事後的版本管理與維護都是讓人惡夢連連之處，對Programer來說，的確非常的不方便。
8.	對於Client端程式的部署與更新，這部份你必須自行負責，或許這也沒太多的技術性，但總是要花時間做到穩定。
9.	基本的安全性管理，這部份本來就必須自行開發，應該必較沒有疑問，大多數的企業或軟件公司都會自己去開發這部份的程序，但是在Server上規劃Security並不是一件簡單的事，必須要有足夠的經驗與規劃能力來完成這個需求。

　　筆者並不是說Delphi有以上的缺點，而是Delphi非常開放，提供了你基本功能並讓你自由發揮，但你也必須通過上面最基本的考驗才能往下發展三層的系統。

如何解決三層問題

　　EEP(Electornic Enterprise Platform)是訊光花了四年所開發的電子化企業平台，是以Delphi 5/7為基礎所開發的3-Tier發展平台，程序員可以輕易以Delphi 5/7用EEP以元件化的方式來開發應用系統，並開放所有元件的Source Code，目的來達到Smart-Client的目的，EEP四年來已經讓百家中大型的企業順利上線使用，所以，我們在此深入探討EEP如何解決以上的問題。

1.	EEP使用了動態的Create TDataSetProvider的技術，Server端使用了一TServiceManager來將一般的TDataModule裡的TQuery自動建立在一個空的TRemoteDataModule中，這樣就可以讓每個U/I畫面的後端的TDataModule獨立出來，各自維護，不必糾纏在一起。
2.	在EEP中透過TserviceManager讓一個TQuery會建立出一個相對的TDataSetProvider，而且會自動建立TDatabase來連線到DataBase主機中，如下圖，因此EEP可以在Server端控制要Create幾個Tdatabase來讓幾個虛擬的TdataSetProvider來共用，這部份就是Connection Pooling的機制，EEP可以輕易控制50個Concurrent的Client僅使用10個Database Connection，來減輕Database的負擔。另一個重點就是TClientDataSet與TDataSetProvider是無狀態的連線方式(隨時保持不連線)，因為TDataSetProvider與TDataBase要讓大家隨時共用的關係，所以導致Client端輸入資料的過程中，Internet可以是斷線狀態(甚至A/P Server也可以重新開啟)，只要事後網路是通的，A/P Server是可以被啟動的，即可將資料存回到Server上。
3.	EEP有提供一個TUpdateComp的元件來負責自動產生精準且100%的Insert/Delete/Update的SQL語法，不但語法精簡(為了增加效能)，而且還提供Insert/Delete/Update時與其他Table的過帳設定，並能自動控制Begin /Commit/RollBack的時機。
4.	EEP有集中式的A/P Server控制中心，各A/P Server間有多少Client上線會相互通知，並且會讓主A/P Server(Master)按各個A/P Server的上線數來平均分配，如此可以面臨更多的Client同時使用系統，目前最大的成功案例已超過600台的Client同時使用8部A/P Server的經驗。
5.	由於TServiceManager元件會依客戶端的ClientDataSet服務時自動配置TDataSetProvider與TDatabase，所以系統即可依Client所指定的Database Name來動態決定TDatabase的資料庫，來達到隨時切換不同Database的功能。
6.	不管是Client端或Server端，EEP把所以的U/I畫面與報表都切割成一個個的BPL為單位，其目的就是為了能讓各個單元成為獨立的應用組件，更容易掛接與抽換模組，讓個別差異較小的企業組件可以容易替換與維護。
7.	EEP採用單一的DCOM Interface，可以讓你隨時掛接到A/P Server的任何Server BPL，這些Server BPL的Method我們提供的特殊的呼叫與傳遞方式，讓你更易維護與開發這些Server Service。
8.	EPP有自動的Web安裝程序，可以透過網站即可為你部署所有的Client，並可以自動比對各個BPL的版本來與A/P Server同步更新模組，達到Client完全免維護的境界。
9.	EEP提供了一組標準的安全管理機制，從Login到Menu功能表的管控都有標準的程序，由於採用開放碼的因素，這些安全管控機制也可以讓企業自行定義。

EEP就是 Smart-Client?

　　微軟大力推廣Smart-Client的觀念與未來的影響，所以我們就以微軟的官方網站所發表的定義來檢驗EEP Delphi 5/7在Smart-Client的能力：

1.	使用區域端的資源：這裡指的包含硬體與軟體的資源，可能是利用區域端的CPU計算能力、記憶體，將生產力軟體連接至企業營運系統；這也是EEP在Client端運用了Windows 98/2000/XP等系列的平台來執行EEP瘦小的Client BPL(基本上每個BPL大約50K到200K間)，其實最重要的是這種Windows U/I用戶必較習慣也容易滿足。
2.	連接：Smart client應用程式通常是大型分散式系統的一部分。例如，應用程式可能跟一系列的Web services溝通，不僅可以維護程式，也不必到處部署與這些更新服務；這部份EEP雖沒有使用Web Server(沒有用到Web Server)，但是以A/P Server來集中提供連接服務與後端的商業處理邏輯，達到的目的是一樣的。
3.	離線的能力：由於可善用區域資源，此類應用程式可讓使用者在缺乏網路連線或是不穩定的狀況下仍可運作。不論是出差需求或是移動工作者，利用桌上型電腦、筆記型電腦，都能在離線時持續運作，而當連線時，也可智慧的自動擷取或更新資料；這部份EEP提供的資料離線的解決方案，共有CAC(CacheConpoment)以Cache元件暫取Local端的資料，再等連線時自動與Server同步；另一方案是在Client端安裝簡易型的資料庫，並利用Client的A/P Server(區域型Server)將會自動記錄所有Local的SQL語法，並當網路連線時將這些SQL語法傳回集中式的主Server上執行以保持資料同步。
4.	智慧型安裝與更新：這是與傳統Rich client最大的差別。以.NET framework為例，系統管理者便可透過檔案複製、下載，或是利用HTTP部署應用程式，同時可以保持自動更新版本的能力；在EEP中，Client的部署也是基本功能。
5.	用戶端裝置的彈性：隨著數位裝置的蓬勃發展，不論是手機、PDA、遊戲機、車用電腦等，新的技術平台也將提供其支援Smart client應用程式架構的能力；這一點是唯一EEP平台無法取代.NET Framework的地方，因此在未來的EEP版本中，也會提供ASP .Net Module的解決方案，來解決此問題。

‧結論‧
　　以上，是以純技術角度分析EEP在Smart-Client中所扮演的角色，不管時代如何演進，IT平台的改朝換代總是每5年到10年發生一次，更讓我們在追逐科技洪流中被淹沒了，科技的進步是一把兩刃尖刀，一邊帶來新的商機與更多的便利性，另一編卻讓我們幾年來所學的經驗完全的喪失殆盡，這也是我們身為科技人的最大的無奈，在我們期待科技的進步與新商機的形成的同時，也期待能保持住前面所做的投資與技術的累積，在跟上與保持距離的拿捏才是軟體公司最難的抉擇，你準備好了嗎？

部份文章參考資料摘自：
Taiwan.CNET.com文章：Smart client有多Smart
Shoppingguide.ithome.com.tw：微軟Smart Client

回上一頁