自從XE4發表以來, 在資料庫連結的介面架構, 我被陷入一個無法評估的現象, 

原本EMBD極力推崇DATASNAP的連結, 針對這部份我也花了很多時間進行了解, 但DATASNAP之難用, 太過複雜的設定及太多元件的置放,
我一直搞不懂, 但XE4發表來, 李維老師指出, DATASNAP未來如BDE般會走向歷史, 所以在XE5出現了一個FIREDAC的架構, 如要因應行動裝置,
使用FIREDAC開發, 但
1. 如果我想要開發3-TIER架構的系統, 在桌機上希望能使用3-TIER方式提供USER使用, 眼下只有DATASNAP可以解決, FIREDAC是如以前
CLIENT-SERVER的兩層架構, 那我到底是要選擇什麼架構來做? 以前直接用CLIENT-SERVER架構開發網路程式, 但ADSL的TCP/IP連通速度
是超級恐怖的慢, 只能靠微軟的遠端桌面技術來克服傳送速度的問題, 但遠端桌面非萬靈丹, 也是存在很多問題, 讓我們在推系統吃足苦頭,
所以當時才會有發展3-TIER的想法, 希望藉由中間層的 APSERVER, 來取代TERMINAL SERVER
2. 開發手機類, 我有看過一些人也是使用DATASNAP在做, 但EMBD告訴我們用FIREDAC, 那FIREDAC的效能如何, 並沒有看到EMBD有提供相關的
效能評估?

所以結論是
DATASNAP是否還可以用, 如果一定要開發3-TIER有沒有更好的選擇, FIREDAC走TCP/IP 的 CLIENT-SERVER架構, 遇到了
ADSL模式會不會"死"一堆

DataSnap會走入一歷史？是dbExpress吧。
FireDAC 有能力走向 Direct Connection ，但可能因為 DataSnap 的關係，所以 FireDAC 在 Mobile 平台目前仍然只能走 DataSnap 繞過去存取資料庫。
所謂的推薦也是後端使用 FireDAC ，前端的 ClientDataSet 不變。

ADSL的問題應該是系統頻寬管理的關係，在原本頻寬就不夠的情形下，再加上系統強制再插手（是Client Driver 還是 DB server 插手就不得而知了），自然連線速度更是雪上加霜。

如果想要 2-Tier 連線最佳化，可參考底下的三方元件：
UniDAC <- 和 FireDAC 相同架構，但連 Mobile 平台也能 Direct Connection ( SQL Server 等 COM 系除外)
SecureBridge <- 中間層軟體
RemoteADO <- 中間層軟體 自製 ADO 元件

===================引 用 P.D. 文 章===================
自從XE4發表以來, 在資料庫連結的介面架構, 我被陷入一個無法評估的現象,

原本EMBD極力推崇DATASNAP的連結, 針對這部份我也花了很多時間進行了解, 但DATASNAP之難用, 太過複雜的設定及太多元件的置放,
我一直搞不懂, 但XE4發表來, 李維老師指出, DATASNAP未來如BDE般會走向歷史, 所以在XE5出現了一個FIREDAC的架構, 如要因應行動裝置,
使用FIREDAC開發, 但
1. 如果我想要開發3-TIER架構的系統, 在桌機上希望能使用3-TIER方式提供USER使用, 眼下只有DATASNAP可以解決, FIREDAC是如以前
CLIENT-SERVER的兩層架構, 那我到底是要選擇什麼架構來做? 以前直接用CLIENT-SERVER架構開發網路程式, 但ADSL的TCP/IP連通速度
是超級恐怖的慢, 只能靠微軟的遠端桌面技術來克服傳送速度的問題, 但遠端桌面非萬靈丹, 也是存在很多問題, 讓我們在推系統吃足苦頭,
所以當時才會有發展3-TIER的想法, 希望藉由中間層的 APSERVER, 來取代TERMINAL SERVER
2. 開發手機類, 我有看過一些人也是使用DATASNAP在做, 但EMBD告訴我們用FIREDAC, 那FIREDAC的效能如何, 並沒有看到EMBD有提供相關的
效能評估?

所以結論是
DATASNAP是否還可以用, 如果一定要開發3-TIER有沒有更好的選擇, FIREDAC走TCP/IP 的 CLIENT-SERVER架構, 遇到了
ADSL模式會不會"死"一堆

Client/Server 連線很慢 這要看資料庫是那個牌子
微軟牌 甲古牌 mysql 連線效率都不錯
azure和amazon google 都可租雲端主機
試過都不差 設備都是拖管 輕鬆就可雲端化
用的人也很多

Interbase firebird兩兄弟 網路架構十分原始
原先就不是設計給Tcp/ip用 很慢是必然
這總資料庫在Internet應用時 應該不能考慮

C/S架構沒那麼不堪
自行打造的中間層 也不見得會比SQL server處理的好

===================引 用 P.D. 文 章===================
自從XE4發表以來, 在資料庫連結的介面架構, 我被陷入一個無法評估的現象,

原本EMBD極力推崇DATASNAP的連結, 針對這部份我也花了很多時間進行了解, 但DATASNAP之難用, 太過複雜的設定及太多元件的置放,
我一直搞不懂, 但XE4發表來, 李維老師指出, DATASNAP未來如BDE般會走向歷史, 所以在XE5出現了一個FIREDAC的架構, 如要因應行動裝置,
使用FIREDAC開發, 但
1. 如果我想要開發3-TIER架構的系統, 在桌機上希望能使用3-TIER方式提供USER使用, 眼下只有DATASNAP可以解決, FIREDAC是如以前
CLIENT-SERVER的兩層架構, 那我到底是要選擇什麼架構來做? 以前直接用CLIENT-SERVER架構開發網路程式, 但ADSL的TCP/IP連通速度
是超級恐怖的慢, 只能靠微軟的遠端桌面技術來克服傳送速度的問題, 但遠端桌面非萬靈丹, 也是存在很多問題, 讓我們在推系統吃足苦頭,
所以當時才會有發展3-TIER的想法, 希望藉由中間層的 APSERVER, 來取代TERMINAL SERVER
2. 開發手機類, 我有看過一些人也是使用DATASNAP在做, 但EMBD告訴我們用FIREDAC, 那FIREDAC的效能如何, 並沒有看到EMBD有提供相關的
效能評估?

所以結論是
DATASNAP是否還可以用, 如果一定要開發3-TIER有沒有更好的選擇, FIREDAC走TCP/IP 的 CLIENT-SERVER架構, 遇到了
ADSL模式會不會"死"一堆