DataSnap三層開發 -- 我的中間層開發，我的 DataSnap
歷史篇
- DataSnap? Midas? 你是誰？我應該選誰？
- 多層，究竟有幾層？試著定義一下。
- DataSnap 能夠解決的問題？
- 決定 DataSnap 輸出的通訊協定
- 決定 DataSnap Sevice 連結資料庫的方式
- DataSnap 有狀態（ Stateful ）開發研討
- DataSnap 可以做和不能做的事
- 我的 DataSnap 開發二部曲 -- 使用 REST DataSnap
- DataSnap 和 MIDAS
- 應用程式和資料庫的關係演變
- 為什麼要用 DataSnap？--兩層的優缺點
- 為什麼要用 DataSnap？--DataSnap 解決兩層問題的方法
緣起篇
抉擇篇
- 對 dbExpress 的誤會
- DataSnap 的開發策略
- 淺談 COM 的開發手法 -- DCOM / MTS
- 淺談 Web Service 的開發手法 -- REST / SOAP
- 該選擇誰？選擇路線圖
- ADO 是個好東西，不用嗎？
DataSnap 實作篇
- 基於 COM 的實作--Server
- 基於 COM 的實作--Client
- 市場成品展示
- 基於 Web Service 的實作
- REST 的實作 -- Server
- REST 的實作 -- Client
- SOAP 的實作 -- Server
- SOAP 的實作 -- Client
- 市場成品展示
- 最終的選擇
結語
=========================================
因為我也不是理論派，
所以目標是把自己開發經驗輸出，理論內容儘可能減少
DataSnap? Midas? 你是誰？我應該選誰？
我想你知道 DataSnap ，但對 Midas 可能有點陌生。但提到 DataSnap 就不能不提到它的過往，底下就來介紹一下。
Midas 全名是：Multitiered Destributed Application Services；
中文是「多層分佈式應用程序服務」。
當時，Oracle
和好朋友 SQL Server 還是個天價計費的時代(現在依然價格不裴)，每一個會連線到資料庫的使用者，都是燒錢的版權費用；而 Borland
和 Microsoft 的資料庫通訊的戰爭也還在持續中，這時 Borland
提出由中間應用層來負責對使用者電腦傳送資料封包，除了可以替企業省錢外，還能夠在通訊協定的戰役上扳回一成。
於是 Borland 開始進行輔導企業導入 Midas 這個工作，很有趣的， Midas 產品是另外收錢的「企業服務」，所以也不是任何企業都想使用這個服務。
隨後，好消息是，Midas 的開放，被納入 Delphi 4 以後企業版的產品線中，於是 Delphi 核心技術之一的多層開發更進一步的讓更多開發人員知道。
Midas 在當時是計畫變為中間層元件 (2003.李維.Borland 傳奇.第四章 未完的傳奇)，那不就是 BDE 嗎！還好 Borland 最後沒有這樣做，有彈性的中間層開發才能面面俱到。
一直到 Delphi 6 ，Borland 為 Midas 改了個名字： DataSnap ，也確定了往後中間層開發的路線，一直到今天，這個路線一直都沒有太大的變化，也因為如此，才有了這篇的出現。
總結：
Midas 歷經 Delphi 3、4、5 ，從 Delphi 6 開始更名為 DataSnap，直到現在的 XE。
本質都是「多層分佈式應用程序服務」。
另外，Oracle 和 SQL Server 的授權方式也因為 DataSnap 而改變，所以省錢的這個條目已經被消滅，還有使用它的理由？
我想，可能還少講了 Kylix，在 Kylix 3 停止開發後，直到 XE 2 ，以不一樣的跨平台開發手法重生。
在 Kylix 還活著的時候，Linux 本身除了 JAVA 外，並沒有比較好的資料庫連線的方法。
DataSnap 也就應用在這個場合上，就算到現在的 XE ，這個理由也依然適用。
多層，究竟有幾層？試著定義一下。
一層：
如果沒有使用到資料庫，那一定是「一層架構」，所有的操作全在使用者的電腦上完成，大都利用序列化陣列來當作資料庫也就足夠滿足需求。
※Delphi.KTOP 的資深版主 Jason Wang 表示：
「dBase、Foxpro 等這類的檔案型資料庫也屬於一層架構的一種。」
所以可以說，沒有內建 Service 的資料庫服務，都稱得上是一層架構。
兩層：
大部分
Delphi / C Builder 的開發者，有聽過
BDE、ADO、DBX、FireDAC……等元件，都是使用兩層架構開發。雖然資料庫和開發機器有可能在同一台電腦上，但脫離不了「資料庫邏輯」←→「應用程式邏輯」或「資料庫存取封包」←→「應用程式資料集」交互的過程。
三層：
DataSnap 即是把 BDE、ADO、DBX、FireDAC 從使用者電腦拉開的仲裁者，而在使用者電腦上看不到上述任何元件的影子，這時開發者必須很清楚資料流各階層的傳遞流程及生命週期，就像程式設計中「變數」的設計週期一樣。
絕大多數的開發者在這個階段，因為對三層的設計方式不熟悉，以及文件資訊不足的惡劣條件下毅然地放棄對 DataSnap 的使用，退守回兩層的開發，這實在是很可惜的事情。
其實 DataSnap 本質並不難，只要關鍵流程透通，三層上的天空很廣大的。
超過三層的「多層」：
你聽過「負載平衡」、「驗證」、「快取」等服務器名稱嗎？這些都是三層架構的一種，因應不同需求而採行的策略，完全取決系統架構的設計導向來定義，沒有一定的套路。
設計前的彈性很足，但框架定義完卻很難修改，所以大型專案必須經過長時間的規畫及時間來鑽研系統的穩定性。
多層大致上已經說完了，是不是還很模糊？
換句話說，就是現在網頁設計規範所提的「前端技術」和「後端技術」
前端：
泛指使用者能夠輕易看到的視覺變化技術。(例如：HTML5、JavaScript 和 CSS)
後端：
使用者看不到的繁瑣處理機制。(例如： PHP、ASP.NET 等)
而連接這兩者中間的那一「層」，就是「中間層」，如同 IIS 所扮演的角色一樣。
多層的架構牽涉的面向太廣大了，所以之後的重心還是放在三層 / 前中後端的內容上。
DataSnap 能夠解決的問題？
Delphi.KTOP 的資深版主 Jason Wang 及 Sryang 等網友提供了很多相關資料，整理了以下內容：
多層架構可以解決兩層的四大問題：
1. 省錢。
2. 跨網際網路的安全性。
3. 資料庫連線數大量增加，造成效能低下。
4. 一致性的使用者端應用程式開發。
先談談如果要解決上述問題，除了 DataSnap 外，兩層架構下有沒有其它解決上述問題的方法？
跨網際網路的安全性問題：
沒有任何一家公司會希望自家的資料庫遭受攻擊，在資訊安全這方面，我們會採用：
1. 防火牆。
2. 軟體或硬體 VPN。
3. 遠端桌面連線。
防火牆的場合：
資料庫仍然需要掛上網際網路，也無法避免 Port Seek （埠位掃瞄）的攻擊，故實務上更改 Port 的方式也很少被採用，頂多是暫時性的權宜做法。
VPN 的場合：
資料庫並不直接連上網際網路，而是透過加密的 VPN 連線，進而讓使用者能夠存取資料庫的資源。
利用 VPN 加密封包及分散處理的效果，達到資料安全性傳輸的功能。
只是連線數造成的資料庫效能低下仍不可避免，以及網路持續連接的能力讓人緊張，如果是跨國連線，恐怕網路穩定性會讓使用者抓狂。
遠端桌面連線的場合：
離資料庫越近的主機越好！只要網路連接有基本良率，就算斷線也只是畫面中斷，下次連線仍然可以接續上次中斷點使用。
最重要的是這種連線方式具有最佳的執行效能。
但因為是畫面傳遞，所需的頻寬必須要有一定的水準，版權數和主機承載能力（兩者指的都是「財力」）是評估的重點。
而且，資料庫在大量連線時的效能損失的問題依然存在，可以保證的是使用者不會因資料庫連線異常導致輸入資料流失。
實戰上也有看到 VPN 遠端桌面連線的雙保險機制同時被使用，提供給開發人員作為參考。
DataSnap 如何能解決兩層開發的問題？
1. 提供 HTTP / HTTPS 及 TCP/IP 兩種通協定，並且可以自定封包格式內容，被破解機率在這一關就大幅下降，等同 VPN 的防護機制。
2. 資料庫連線數問題，連線數太多會造成資料庫效能降低；但太少時所花在連線交握的時間也不會讓使用端佔上太多便宜。這部份的微調可視實際場合使用「連接池」（ Connection Pool ）來降低連線消耗。
3. 連線不穩定的問題，如果 DataSnap 採用「無狀態」（Status-Less）設計模式，在離線狀態下仍能進行編輯工作，等到連線狀態穩定後再與資料庫同步即可；這和微軟提出的「公事包」概念有異曲同工之妙。
只是 DataSnap 要做到上述的功能，大都需要自己額外寫程式，看到這裡想打退堂鼓的人應該不少。
按照 DataSnap 歷史路線來看，想要省力開發也不是沒有方法，RemObject Data Abstract 就是其中一個很好的合作夥伴。
所謂的歷史路線指的是：Borland 一直到現在的 Embarcadero 本身沒有足夠的資源可以完善 DataSnap Server 端，所以讓 3rd-Party 廠商來合作完善，各位可以驗證看看現在的路線是不是依然使用合作策略方式。
當然不甘寂寞的高手們（沒錯！指的就是現在看這篇的你！），DataSnap 也提供原始碼讓開發者來設計符合自己需求的 Service ，喜歡全架構運籌帷幄的開發者們快來挑戰吧！
決定 DataSnap 輸出的通訊協定
DataSnap 提供豐富的傳輸方式。其中包含：
基於 (D)COM / COM (MTS) 的有：
- Socket
- Web HTTP
基於通用協議的有：
- CORBA
- SOAP
- RESTful
在 XE 之後的版本，基於 COM 的 DataSnap 已經停止開發新的功能。
主要的原因是基於 COM 的 DataSnap 無法在行動裝置上被使用。
但如果仍然是以 Windows 桌面平台為主力，使用 COM 版的 DataSnap 仍然能享有最大效能的網路傳輸服務。
DataSnap 區分為 Server 端和 Client 端設計。
基於 COM 的場合：
Server 端設計上又分為邏輯程式及橋接程式設計：
1. 邏輯程式設計：以 COM / MTS 等註冊元件服務的方式存在。
2. 橋接程式設計：決定 Client 可以使用 Socket / HTTP 的通訊協定連入。
Client 端：
依照 Server 能夠提供的通訊協議，設定指定的連線元件進行連接。
基於通用協議的場合：
代表
CORBA 開發的 VisiBroker 在 Delphi 7 之後的版本已悄悄消失，不再被預載入 Delphi 的產品內，有在開發
CORBA 版 DataSnap 的開發者一定底子很好。但我是直接放棄它的使用，哪怕它有再好的能力，因為 Delphi 早已不支援 CORBA
新的技術版本了。
SOAP 在 Delphi 5 時可紅極了，設計 SOAP 的技術資料不斷的被推出，只是 SOAP 的技術理論要搞懂真的不是件簡單的事，Delphi 真的把 SOAP 變簡單了嗎？
RESTful 是從 Delphi 2009 加入的開發方向，基於 Indy WinHTTP 技術再替 DataSnap 注入新的氣象，在當時行動裝置主要以 JSON 做為與伺服器的資料交換，於是 RESTful 就此晉陞為跨平台解決方案的主力。
Server 端：
邏輯和橋接會併入同一個開發專案使用，Delphi 按服務通用規範打造橋接程式內容，使用者只需專注在邏輯程式的開發即可。
Client 端：
依照 Server 能夠提供的通訊協議，設定指定的連線元件進行連接。
以上可以得知，不論 Server 端如何變化， Client 端的設計是很固定的。
而且，它的通訊協議也有個專屬名詞：MIDAS
決定 DataSnap Sevice 連結資料庫的方式
既然要把 Database 連接元件抽離，就免不了還要重新決定哪一種連線方法。
當然如果已經有喜好的連接元件，也是可以直接使用，並不是說 DataSnap Service 就必須採用特定元件。
Delphi / C Builder 提供了以下元件：
BDE （Borland Database Engine）
經典中的經典，強大的 BDE Administrator 可以說是老 Delphi 開發者美好回憶。雖然最新版的 XE 已經把 BDE 排除在安裝包中，但對 BDE 有執念的開發者，還是會想方設法地把它找回來。
*ID: 29997, BDE Installer for RAD Studio, Delphi, C Builder XE7
只是 BDE 在停止維護後， Unicode 的支援計畫也隨之停止，對於這讓人又愛又恨的元件，還是讓它還給歷史，擦擦眼淚，來看下一組元件。
ADO（ActiveX Data Objects） Express / dbGO
Borland
重新包裝 ADO 後，所做出的超完美元件組。在經歷的十餘年後，才有了可以和它相提併論的 FireDAC 。在這段期間，能走出 BDE
傷痛的開發者，絕大多數都選擇了 ADO ，它的穩定性及 SQL Server 完美搭配，再也沒有元件能出其右。
dbExpress
這個元件組很有戲，當時的開發市場情形簡述如下：
1. Borland 為了擺脫微軟的陰影。
2. 因應 BDE 停止開發後所帶來的衝擊。
3. Borland 高層決定推廣 DataSnap 技術。
於是 dbExpress 就在這個期待下誕生了，當時 dbExpress 的教學如雨後春筍般的不斷冒出。
只是， dbExpress 面臨了以下的問題：
1. 和 BDE、ADO 的開發方式有很大的矛盾。
2. dbExpress 的 Driver 完成度不足。
dbExpress
先天就是以搭配 DataSnap 為前提的元件，所以它的設定非常的簡單，而且和 BDE、ADO 相比，只有它們一半的功能，另一半則由
TDataSetProvider 及 TClientDataSet 來實現，這就和原本使用 BDE 和 ADO
的開發者的使用習慣完全不同，而所有關於 dbExpress 的書，對於 DataSnap 也沒有多所著墨，一律視為 dbExpress 框架。
導致讓開發者認為 dbExpress 是個很囉嗦的元件組。可是卻又不得不承認，在兩層架構下，dbExpress DataSnap 真的很囉嗦。
然而 dbExpress 設計的方式真能順利把兩層架構無痛升級三層架構嗎？
另一個讓人垢病的就是
dbExpress Driver，由於 Borland 採用的是三方廠商共同支撐這部份的技術支援路線，所以自家開發的 dbExpress
Driver 只相容於 InterBase ，其它 dbExpress Driver 寫得是問題很多；大部份的開發者，包含當時為
dbExpress 寫書的作者，都經過 dbExpress Bugs 的洗禮。
從 dbExpress 1.0 一直到 4.0 後，在 RAD Studio XE7 的說明文件中，正式宣告 dbExpress 停止開發，也算是終止了開發者為 dbExpress Bugs 糾結的惡夢。
目前使用上，我認為 dbExpress 是設定最無腦的元件組，但如果有餘力，買個 dbExpress Driver 就更完美了。
dbExpress ODBC driver 也是追求穩定的另一選擇。
FireDAC
Embarcadero
於 2013 年買下 AnyDAC 後，結合 FireMonkey framework ，正式更名為 FireDAC，它並不是只能用在
FireMonkey application，VCL application 也同樣能享受這高效能的資料連結元件。
FireDAC 和 dbExpress 一樣，也是透過不同的 Driver 來達到對不同種類的資料庫支援，但設計方式屬於道地的兩層架構，這對原本使用 BDE 和 ADO 的開發者來說衝擊較小，所以一堆出便大受開發者的青睞。
如果是兩層開發，選擇就相對簡單：
- 使用微軟方庫或只能使用 ODBC 的資料庫，就用 ADO。
- EMBT 支援的資料庫或對 TDataSet 的操作一致性就用 FireDAC。
有買 DBX Driver 的，就繼續沿用或是透過 FireDAC 加載，這可以說是將 DBX 做 2-Tier 化的好方法。
但要使用 DataSnap，必須再重新思考這四大元件的選擇。
WebBroker？
我真的是忘記它了，當時在研究 REST DataSnap 還有向李維老師請教這兩者的不同。
李老師的說法是：
DataSnap Rest Appliation是為DataSnap伺機器加入REST的功能, 可執行在Web Server中
主要目的應該是為了把早期WebBroker或是Internet Express應用程式昇級成DataSnap伺機器,
本質的應用上是不一樣的：
REST Application = JSON Package 輸出
WebBroker Application = HTML Text 輸出，不含 RESTful DataSnap 底層
實際設計上，
REST Application 算是自動為專案配好 RESTful 輸出的底層(JQuery JS)及基本功能。
WebBroker Application 只是半自動的輸出底層，其它功能需要設計者自行產出，2009 後額外提供 RESTful DataSnap 輸出的能力。
不管是實驗還是商用開發，DataSnap 能提供的是：「沒有最好用，只有最合用」，要最好用，請找 3rd (笑)。
哪怕是商用開發，如果客戶衝不上 10 個，使用實驗版的 DataSnap 反而能在 Client 端開發快速應變，用實驗版也無傷大雅。(只是公司燒錢會很不爽啦)
DataSnap 有狀態（ Stateful ）開發研討
做為一個簡單易用的 DataSnap，書上的範例是這麼寫的：
基於 COM 架構：
基於 RESTful 架構
咦？好像差不多？
因為實在太像了，所以好像沒什麼變化，坊間有提到 DataSnap 的書籍大都是這樣的寫法。
先來說說萬年範例在實作上有什麼好處：
1. 需要的 Table 或 Query 可以一口氣全丟到 TDataModule，在 Client 端只需要呼叫指定的 TDataSetProvider 即可。
2. 不論是 Server 或 Client 在設計資料存取上都非常簡單，可以全力專注開發 UI/UX 介面。
缺點是：
1. 當 Table 或 Query 變多時，Server 會堆積非常多的元件，久了會造成設計時的災難。
2. 多數 DataSet 被開啟時，Server 負載會非常沉重，頻寬也會被大量佔用。
3.
不論是 COM-base 或 REST-base，Server 對於多 Client 的處理都是採 Blocking 模式，Stateful
設計下若有大量 Client 開開關關 DataSet，Server 上光是排隊處理資料載入就會更浪費系統資源。
Com-base DataSnap 在有狀態的設計下，還有 Client 異常斷線造成 Session 無法釋放的問題，除了坊間外，新的版本上也是利用「超時釋放」的方式來解決，雖然做得不漂亮，但至少是解決問題了。
REST-base DataSnap 在 Client 交握上就寫得比較好，幾乎沒有發現有 Session 卡在 Server 上的問題，明顯感受到 DataSnap 進步了。
REST-base
架構在 Server 端還可以在 TDSServerClass.LifeCycle 下設置 Session 行為，調整為
Invocation，立馬就將 Stateful 改變為 Statusless，REST DataSnap 穩定性將會提高。
REST-base 看起來是不錯的選擇，COM-base 可以靠邊站了嗎？
按照近幾年 Delphi XE 的 What's New 所提及到 DataSnap 的資料所示，REST DataSnap 的傳輸效能還有再往上的空間，在實戰上也確實是慢得讓我被使用者駡到臭頭。
DataSnap 可以做和不能做的事
DataSnap 產品開發這麼久，整理一下到目前為止，DataSnap 能做和不能做(或難以實現)的工作。
事實上，DataSnap 重點只在於資料的交換，所以在設計上 DataSnap 可以輕鬆做到的事情有：
自定義文字格式的傳輸，XML、JSON 的格式還有各自的元件可以幫忙解析。
半人工：
壓縮、加密封包很簡單，除了 SSL 外，還能夠自己決定壓縮功能及自訂的加密（RSA、MD5等）方法，在 SSL 現在已經沒這麼安全的網路世界中，透過自訂加密法更能保護自家的資訊安全。
負載平衡(Load Balancing)：COM-base 有個 TSimpleObjectBroker 元件可以輕鬆在用戶端完成這個工作，但在 REST-base 下就只能自己全人工設計，可以在仿照這個元件的設計概念重新實作看看。
介紹完可以做的事後，接著不能做或難以實現的工作也要提一下：
分頁任務完全無法勝任；在 DataSnap 的官方設計上，有提供分頁設計方法只有一個：TClientDataSet.PacketRecords。這還是在 Stateful 下，也就是先前提到的萬年範例才能夠支援的屬性。
那 DataSnap 完全無法做到分頁功能？
當然可以，你能透過 TDataSetProvider.OnDataRequest 事件，把用戶端當前的狀態（如頁數、表格名稱等），然後開始實作。
或是採用網頁設計中常見的手法──使用 SQL 限制輸出筆數，來達成分頁的效果。
嚴格來說，分頁不在 DataSnap 的設計規範中，所以「分頁」任務對 DataSnap 來說只能是一種奢求。
我的 DataSnap 開發二部曲 -- 使用 REST DataSnap
按照近幾年 Delphi XE 的 What's New 所提及到 DataSnap 的資料所示，REST DataSnap 的傳輸效能還有再往上的空間，想要在萬年範例上使用 REST DataSnap 要有心裡準備。
但 REST DataSnap 可是跨平台的第一交椅，非得用它不可。
所以在衍生出參數化查詢的做法，並回傳物件集合，如：TJSONArray 等。
當然，這也和 FireMonkey 的 LiveBinding 有關係，可以直接和物件關係綁定，這是新的概念。
除了新概念外，能大量減少不必要的資料傳輸才是加快反應時間的問題核心。
REST DataSnap 提供底下兩種傳輸方法：
TDSProviderConnection：對應的就是 REST DataSnap 裡的 TDataSetProvider。設計方式依循 Com-base DataSnap 的做法：一個 Table / Query 一個 ClientDataSet。
後來因為這方式太不靈活，於是我採用的是另一種方法：
REST function：利用公開的函式庫，下載所需要的物件，再另行處理。
一層非常好用，BDE的採用
那Access怎麼不考慮？
因為公司沒買。（冷）
好吧，接著便是發展所謂單機版的資料庫應用程式，話雖如此，也是過了一年的快樂時光。
Database Desktop、BDE、PX、DB、Repair Paradox Tables等，我想有接觸過的開發者就不用多談，還沒用過的，應該也不需要再用它了。
新奇的技術 -- dbExpress
開始瞭解BDE以外的資料庫連結方式，在當時天真的以為dbExpress就是資料庫程式設計的全部。
不論如何，開始了我進入兩層架構的階段。
dbExpress Component TDataSetProvider TClientDataSet，每每在設計程式介面時，都不覺得麻煩，總覺得dbExpress怎麼能做到這麼多畫面的變化，現在回想起來還覺得好笑，那是Data Aware Components，並不是dbExpress限定的。
當時的MySQL已經進入5.x的版本，4.0顯得已經落後許多，接著開始嚐到dbExpress Driver的惡夢，各家的Driver對於MySQL版本的支援度都不相同，幾經嚐試，都快要放棄對它的使用。
後來找到「Just Software Solutions DbExpress drivers for MySQL V5.0」
（https://www.justsoftwaresolutions.co.uk/delphi/dbexpress_and_mysql_5.html），這位開發者真是佛心來的，免費開放給Delphi / C Builder的開發者使用，C Builder 6和MySQL 5.0.51a也能搭配得相當愉快。
在練習一陣子後，意外地發現有個可以替代Paradox，而且還能商業應用的資料庫服務：Firebird，更重要的是，dbExpress Driver是針對Firebird孿生兄弟－－Interbase V6.0而設計，對於Firebird也發揮了百分之百的相容性。
 |
| Firebird資料庫 圖片來源：Firebird官方網站 |
瞭解Firebird和Interbase的關係後，便花了好長一段時間在BDE轉化為DBX的資料連結元件上，瞭解到更換升級並不是想像中這麼困難。
而關鍵的TClientDataSet也能順利和其它三方元件（如：QuickReport、Indy等）一同工作，在這個階段也算是我在DataSnap上完成了初步學習，只是當時還是傻傻地不明白為什麼寫個程式原來是這樣麻煩的道理。
就在整個專案導入了dbExpress之後，卻發生了下一件事情。
「客戶想要Web版。」
其實這篇的內容比較和DataSnap沒有直接的關聯。
話說，客戶要求Web化的理由很簡單，就是希望能在出差的時候也能掌握設備的動態。
這不就是互聯網的概念嗎！想法很先進，可惜太早了，Delphi引進物聯網概念也是2014年時的事情。
當時有考慮過IntraWeb，只是當時它的支援度很另人緊張——因為並不支援當時全球第一大瀏覽器：Internet Explorer 6。
 |
| Atozed Software - IntraWeb 圖片來源：Atozed |
幾經試作後，IntraWeb的開發方式比較接近ASP.NET 1.0的網站絕對定位設計方法，甚至IntraWeb還可以做到不需要瞭解HTTP、CSS和JavaScript就能完成網站的架設。
你棒棒你，想不到這產品這麼威能。
可惜， 最後還是敗在不能提供IE6的網頁的缺陷下而被否決。
最後在當時個人實力有限的慘況下（另一說是IntraWeb花了太多時間練習），只好請功力深厚的同事操刀，最終拍案，採取PHP來進行網站後端程式開發。
而使用PHP開發，想當然爾，資料庫九成九一定會選擇MySQL，果真沒錯，就是MySQL。
兩種異質資料庫並行的情況下，資料同步又是另一個問題，而且又是要讓PHP讀取即時資料，採C Builder進行資料同步勢必還是有延遲時間。（事後回過頭來想，好像也沒有延遲多久，多濾了）
但才剛改成FireBird資料庫的我，還沒來得讓我思考PHP能不能連結FireBird，主管早搶一步表示案子進度已經燒屁股了，怎麼有膽量再去挑戰PHP和FireBird的相容性。
再把FireBird換回MySQL吧！
dbExpress經驗值 2。
該放棄Web還是C Builder？
回補一下關於Delphi/C Builder在Web上的開發方案，我整理了以下的簡圖：
不論是WebBroker、Internet Express還是WebSnap，最大的問題在於「HTML、CSS、JavaScript」等Browser Client的糾結。對於已經習慣VCL元件的開發者，勢必又是另一個頭痛的戰場。
直接看一下沒有HTML和CSS概念下，所產出畫面：
再來看現在新版JQuery UI基本款可以做到什麼樣的畫面：
雖說美感是見人見智，但大多數人應不滿意標準HTML的表現，不然也不會有JQuery UI的產生。
只是忙於商業邏輯就無力分身的開發員，還要學習Browser Client技術，VCL的優勢明顯派不上用場。
此時VCL for Web，也就是現在的IntraWeb，解決的就是這個問題。
原有Win Form的開發概念可以照搬上Web Form來進行開發。
IW有個最大的優點，也是最大的缺點－－RunTime時期針對不同呼叫的Browser，產出配合Browser的HTML。
也就是說，原Win Form的開發者不再需要考慮Browser版面的處理，完全交由IW做自動最佳化的處理。
這是優點，反過來說也是缺點，對於Browser版本的限制，導致必須隨著Browser升級，或變更時，也要跟著升級IW。
另一方面，IW是版權軟體，當時的相容性又堪慮。在這種花錢還受罪的場合下，綜合得出C Builder沒有更為合適的Web開發的解決方案。
砍掉C Builder重練是否為最好的選擇？
再談Web化
會採用Web化的原因是，現在所有的作業系統中，一定會有瀏覽器，所以就沒有軟體安裝的問題，Web的安全性也相對得要比Win Form要來得好一點。
但事實上，如果Web安全性這麼高，就不需要防毒軟體存在。
從瀏覽器被綁架的事件滋生不斷中就可以得出，Web安全性也有它的漏洞存在。
被封裝好的執行檔（EXE）就一定不安全嗎？
在人手一機，還必備防毒軟體的現況下，執行檔有個什麼閃失就容易被防毒軟體抓去「收容」，執行檔就必不安全？
執行檔還有另一問題，就是部署了。
Inno Setup、InstallAware和InstallShield等都是解決部署問題的方法。
那麼執行檔變Portable（免安裝）化不可以嗎？
要讓使用者享受物聯網服務，就只有Web可以選擇？
說穿了，最終就只是載具問題罷了。
那穿透網際網路，執行檔直接穿透網際網路連接資料庫，光是安全性話題就足夠戰好幾回合，在這邊就不表了。
而C Builder有什麼可以跨網際網路的資料連結方案？
現成的概念就是MIDAS－－分散式應用系統。
現在是開發兩層還是三層？
DataSnap的開發畫面大概是這個樣子：
好像有點一樣，又好像有點不一樣。
如果dbExpress改一下，就變成下面的畫面：
相較之下，dbExpress好像只差了一個TDCOMConnection元件外，和DataSnap長相簡直一模一樣。
也難怪dbExpress要被人說閒話了，這複雜
說易用沒有BDE來得自動化：TQuery TUpdateSQL，BDE小小調整一下，收工。
說功能沒有ADO來得全面：光是ADOConnection的Properties內容就可以談上十餘頁A4紙；ADOQuery幾乎把BDE元件所有功能包完。
反觀dbExpress，Driver Params就只有幾項，光產出的元件就比BDE多，程式的所有細節居然還全都要人工硬嗑，就算不寫程式碼，需要看的資料也絕對不下於ADO。
那dbExpress的架構到底是什麼？Borland開發這個是拿磚頭砸自己的腳嗎？
用到現在，我終於參悟了dbExpress到底是什麼，算得上是三層嗎？
如果只能用一句話來描述dbExpress的層數，那我想我會說：
「兩層以上，三層未滿」
沒有留言:
張貼留言