當然如果已經有喜好的連接元件，也是可以直接使用，並不是說 DataSnap Service 就必須採用特定元件。
Delphi / C++ Builder 提供了以下元件：
 |
| BDE 元件盤 |
經典中的經典，強大的 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 的洗禮。
RAD Studio XE7 的說明文件中，宣告 dbExpress 停止在行動裝置的開發，將 dbExpress 納入 DataSnap 的標準配備，並以 FireDAC 導正為 2-Tier 資料庫設計的最佳方案。
目前使用上，我認為 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，必須再重新思考這四大元件的選擇。
--- 未完待續 ---
沒有留言:
張貼留言