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 ，這個理由也依然適用。

編輯記錄

等你下集 ^^

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

多層，究竟有幾層？試著定義一下。

如果沒有使用到資料庫，那一定是「一層架構」，所有的操作全在使用者的電腦上完成，大都利用序列化陣列來當作資料庫也就足夠滿足需求。
「dBase、Foxpro 等這類的檔案型資料庫也屬於一層架構的一種。」

Delphi / C Builder 經典的兩層架構

大部分 Delphi / C Builder 的開發者，有聽過 BDE、ADO、DBX、FireDAC……等元件，都是使用兩層架構開發。雖然資料庫和開發機器有可能在同一台電腦上，但脫離不了「資料庫邏輯」←→「應用程式邏輯」或「資料庫存取封包」←→「應用程式資料集」交互的過程。

DataSnap 定義的三層架構

DataSnap 即是把 BDE、ADO、DBX、FireDAC 從使用者電腦拉開的仲裁者，而在使用者電腦上看不到上述任何元件的影子，這時開發者必須很清楚資料流各階層的傳遞流程及生命週期，就像程式設計中「變數」的設計週期一樣。

其實 DataSnap 本質並不難，只要關鍵流程透通，三層上的天空很廣大的。

你聽過「負載平衡」、「驗證」、「快取」等服務器名稱嗎？這些都是三層架構的一種，因應不同需求而採行的策略，完全取決系統架構的設計導向來定義，沒有一定的套路。

多層大致上已經說完了，是不是還很模糊？

前端：
後端：
而連接這兩者中間的那一「層」，就是「中間層」，如同 IIS 所扮演的角色一樣。

--- 未完待續 ---

編輯記錄

DataSnap 能夠解決的問題？

Delphi.KTOP 的資深版主 Jason Wang 及 Sryang 等網友提供了很多相關資料，整理了以下內容：

多層架構可以解決兩層的四大問題：
1. 省錢。
2. 跨網際網路的安全性。
3. 資料庫連線數大量增加，造成效能低下。
4. 一致性的使用者端應用程式開發。

先談談如果要解決上述問題，除了 DataSnap 外，兩層架構下有沒有其它解決上述問題的方法？

跨網際網路的安全性問題：
沒有任何一家公司會希望自家的資料庫遭受攻擊，在資訊安全這方面，我們會採用：

1. 防火牆。
2. 軟體或硬體 VPN。
3. 遠端桌面連線。

防火牆的場合：
資料庫仍然需要掛上網際網路，也無法避免 Port Seek （埠位掃描）的攻擊，故實務上更改 Port 的方式也很少被採用，頂多是暫時性的權宜做法。

VPN 的場合：
SecureBridge 是軟體 VPN 中的佼佼者。圖片來源： Devart 資料庫並不直接連上網際網路，而是透過加密的 VPN 連線，進而讓使用者能夠存取資料庫的資源。

利用 VPN 加密封包及分散處理的效果，達到資料安全性傳輸的功能。

只是連線數造成的資料庫效能低下仍不可避免，以及網路持續連接的能力讓人緊張，如果是跨國連線，恐怕網路穩定性會讓使用者抓狂。

遠端桌面連線的場合：
Windows 內建的遠端桌面有較佳的幀率
離資料庫越近的主機越好！只要網路連接有基本良率，就算斷線也只是畫面中斷，下次連線仍然可以接續上次中斷點使用。

最重要的是這種連線方式具有最佳的執行效能。

Citrix 的遠端桌面對網路頻寬的要求極低 但因為是畫面傳遞，所需的頻寬必須要有一定的水準，版權數和主機承載能力（兩者指的都是「財力」）是評估的重點。

而且，資料庫在大量連線時的效能損失的問題依然存在，可以保證的是使用者不會因資料庫連線異常導致輸入資料流失。

實戰上也有看到 VPN 遠端桌面連線的雙保險機制同時被使用，提供給開發人員作為參考。










--- 未完待續 ---

 1. 提供 HTTP / HTTPS 及 TCP/IP 兩種通協定，並且可以自定封包格式內容，被破解機率在這一關就大幅下降，等同 VPN 的防護機制。

3. 連線不穩定的問題，如果 DataSnap 採用「無狀態」（Status-Less）設計模式，在離線狀態下仍能進行編輯工作，等到連線狀態穩定後再與資料庫同步即可；這和微軟提出的「」概念有異曲同工之妙。

按照 DataSnap 歷史路線來看，想要省力開發也不是沒有方法，RemObject 就是其中一個很好的合作伙伴。

RO DataSnap Server 端設計畫面。圖片來源：RemObjects

當然不甘寂寞的高手們（沒錯！指的就是現在看這篇的你！），DataSnap 也提供原始碼讓開發者來設計符合自己需求的 Service ，喜歡全架構運籌帷幄的開發者們快來挑戰吧！







--- 未完待續 ---

 

決定 DataSnap 輸出的通訊協定

編輯記錄

讚喔! 這算是 the old new thing :) 舊友新知 都值得看。 keep going!

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

謝謝蕭大的支持！

各位如果其它的見解或是想了解的地方，也歡迎回覆分享！

===================引 用 aftcast 文 章===================
讚喔! 這算是 the old new thing :) 舊友新知 都值得看。 keep going!

 

決定 DataSnap Sevice 連結資料庫的方式

感謝RuRu 的分享, 
去年底上了李神(容我這樣稱呼李維老師, 現在很夯的用法)的資料庫進階課程, 針對現在 XE 系統的 DataSnap 做了很深入的批註及說明, 有些可能涉及專技就不在此談, 但李神針對DataSanp說明了, 現有 XEn 的 DataSanp 有三種層次

1. DataSanp Server
2. DataSnap Rest Server
3. DataSanp Web Broken

第1種是適用在實驗開發的架構, 課中也透過一些實證檢測給我們看, 大約超過30個瞬間連入 connect 就開始 Lost & Error , 所以建議真的要開發商業模式的三層, 採用2,3種方式, 然而第2,3種均以Json模式傳導資料, 所以難度會有的, 同時想要突破更多連入數, 還是有好幾個動作要進行程式的調校, 並不是直接使用內建的2,3種就萬無一失, 可惜這方面對我來說不是專精的項目, 所以課程中還是有很多懵懵懂懂的章節, 加上公司業務繁忙, 課後也沒有太多時間可以進行了解, 如果在這方面有深入研究的網友願意分享那就更好了

編輯記錄

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 端開發快速應變，用實驗版也無傷大雅。(只是公司燒錢會很不爽啦)

謝謝 PD 大分享上課心得！



===================引 用 P.D. 文 章===================
感謝RuRu 的分享,
去年底上了李神(容我這樣稱呼李維老師, 現在很夯的用法)的資料庫進階課程, 針對現在 XE 系統的 DataSnap 做了很深入的批註及說明, 有些可能涉及專技就不在此談, 但李神針對DataSanp說明了, 現有 XEn 的 DataSanp 有三種層次

1. DataSanp Server
2. DataSnap Rest Server
3. DataSanp Web Broken

第1種是適用在實驗開發的架構, 課中也透過一些實證檢測給我們看, 大約超過30個瞬間連入 connect 就開始 Lost & Error , 所以建議真的要開發商業模式的三層, 採用2,3種方式, 然而第2,3種均以Json模式傳導資料, 所以難度會有的, 同時想要突破更多連入數, 還是有好幾個動作要進行程式的調校, 並不是直接使用內建的2,3種就萬無一失, 可惜這方面對我來說不是專精的項目, 所以課程中還是有很多懵懵懂懂的章節, 加上公司業務繁忙, 課後也沒有太多時間可以進行了解, 如果在這方面有深入研究的網友願意分享那就更好了

 

DataSnap 有狀態（ Stateful ）開發研討

WebBroker 開發出來是 dll 的模式, 可供 Web 來呼叫, 也算是比較輕量型的 DataSnap, 它的效能是比較高的, 
但的確, 如果連線人數衝不到臨界點, 我覺得使用第1種也是足夠的(我是這麼認為)
目前的開發也還是使用 DataSnap Server 為基礎, 預計年後就要發表給客戶使用, 到時就可以得到一些數據了
===================引 用 GrandRURU 文 章===================
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 端開發快速應變，用實驗版也無傷大雅。(只是公司燒錢會很不爽啦)

謝謝 PD 大分享上課心得！



===================引 用 P.D. 文 章===================
感謝RuRu 的分享,
去年底上了李神(容我這樣稱呼李維老師, 現在很夯的用法)的資料庫進階課程, 針對現在 XE 系統的 DataSnap 做了很深入的批註及說明, 有些可能涉及專技就不在此談, 但李神針對DataSanp說明了, 現有 XEn 的 DataSanp 有三種層次

1. DataSanp Server
2. DataSnap Rest Server
3. DataSanp Web Broken

第1種是適用在實驗開發的架構, 課中也透過一些實證檢測給我們看, 大約超過30個瞬間連入 connect 就開始 Lost & Error , 所以建議真的要開發商業模式的三層, 採用2,3種方式, 然而第2,3種均以Json模式傳導資料, 所以難度會有的, 同時想要突破更多連入數, 還是有好幾個動作要進行程式的調校, 並不是直接使用內建的2,3種就萬無一失, 可惜這方面對我來說不是專精的項目, 所以課程中還是有很多懵懵懂懂的章節, 加上公司業務繁忙, 課後也沒有太多時間可以進行了解, 如果在這方面有深入研究的網友願意分享那就更好了

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

以下是我整理的主題方向

歷史篇
DataSnap 和 MIDAS
應用程式和資料庫的關係演變
為什麼要用 DataSnap？--兩層的優缺點
為什麼要用 DataSnap？--DataSnap 解決兩層問題的方法

緣起篇
一層非常好用，BDE 的採用
新奇的技術，dbExpress
客戶的要求，Web 化
該放棄 Web 還是 C Builder
現在是開發兩層還是三層？

決擇篇
對 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
市場成品展示
最終的選擇

結語

因為我也不是理論派，
所以目標是把自己開發經驗輸出，理論內容盡可能減少

只是不曉得大家有沒有興趣就是了，哈哈

編輯記錄

非常的好!  建議寫的時候就用一些排版軟體寫好再來貼文。因為…這麼多的內容，相當於一本書了。在你貼完的同時，我想可以拿去順便出版，qcom是個出版的選擇，因為他們曾提過。一魚二吃!

即便或許大家對某些技術的看法有分崎，但都值得去品味、去吸取、淬煉以補不足之處。

期待你的作品。 ^_^

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

写得非常好！


我补充一点点：

我买过李维的所有的书。通过李维的书入门多层架构后，也在几个比较大的项目上实际运用过。谈谈我的实际经验。

1. COM Based 的架构：其实这种架构，如果采用 COM ，效率是非常高的。一套系统，后端 SQL SERVER 只需要10个连接，前面顶200个 UI 前端，一点问题都没有。
2. 我自己后来通过学习李维关于 WebService 的书，后来做的东西都转为采用 WebService 了，对 WebService 还算熟悉。目前暂时还没时间实际去适应 REST 架构，所以对新的 REST DataSnap 不熟悉。

要做多层架构的东西，最重要的，是一定要去掉以前做2层或者单层架构时，在 UI 客户端直接连数据库的使用习惯。这个使用习惯背后，其实就是【状态】。

Delphi 做多层架构，就是在客户端使用 ClientDataSet。传统的 COM Based 下，默认给出的使用方式，和两层非常类似，也是有状态的。这样，不熟悉三层架构但熟悉两层的人，非常容易上手，而且拖拉几个元件，也就可以做出一个简单的程式来。但是，这样并不是真正理解了三层架构。

真正要理解三层架构，一定要做到【无状态】（Staeless）。理解了【无状态】，也就不存在翻页的问题了 --- 翻页，应该是数据库 SQL 要解决的问题。

如果你做过网页，不管是 ASP, ASP.NET 还是 PHP 还是 WebBroker，你应该就知道，网页和后端服务器是脱离开的。一次访问，网页打开后，你的页面（Web Browser）就已经断开和 Web Server 的 TCP 连接了。如果这时候你需要下一页数据，点了【下一页】，前端网页（HTML, JavaScript）会将当前页的相关参数（一般是该页里面最大的数据的主键值）传递给 WebServer， Web Server 端的 ASP/ASP.NET/PHP 等等，根据这个值，通过 SQL 语句向 DataBase Server 要下一页的数据。

上述过程，就是一个无状态的过程。所谓无状态，是指服务器端没有保存客户端的状态，服务器端根本不知道客户端的【下一页】是从哪条数据开始的。客户端需要下一页，必须告诉服务器端自己当前要从哪条数据开始。至于【一页】包含多少条数据，也可以由客户端告诉服务器端，你也可以 hard code 硬编码写死在服务器端的代码里面。

在 Delphi DataSnap 底下，一样必须要这样做，这个三层才有三层存在的意义。最大的好处就是：客户端从服务器端拉完数据，就断开了和服务器端的连接（如何断开连接的？等一下说。），这样，服务器端就可以服务器其它客户端的连接请求。这样，才可以一台服务器，10个数据库连接 license 就能支持200个以上的客户端的访问。这样做更大的好处是，当那台服务器顶不住更多客户端的访问的时候，你加一台跑中间层的服务器就好了。对于客户端来说，因为是无状态的，它可以上一次从 A 服务器拉数据，下一次把数据提交给B服务器，哪个不忙就找哪个（这就是传说中的负载均衡）。

至于使用 DataSnap 要做到无状态，你必须得自己多写点代码，而不是拖拉几个元件就完成。

对于前端UI程式的数据需要提交到 DataBase Server 来说，也一样：提交的时候，前端（或者叫客户端）连接中间层（或者叫服务器端），将数据提交过去，中间层负责把数据真正提交给 DataBase Server，中间层的代码是你自己写的，你可以在这里，写一些权限控制等业务逻辑代码，决定是否允许提交等等业务逻辑。

这里讲的这些概念，本质上是由 Midas.dll 提供的一个功能来实现的：服务器端通过 DataSetProvider 将来自 DataBase Server 的数据打成一个包，然后通过网路通信协议（比如 TCP）丢给客户端；客户端将这个封包，丢给 ClientDataSet，你就可以通过绑定到 ClientDataSet 的 DBGrid 看到数据了。如果你在 DBGrid 里面编辑了数据，需要提交，则客户端向服务器端发起建立一个网路连接，然后将需要提交的数据打成一个包（我们甚至可以看到这个包是一个 OleVariant 格式的 Data），通过网路通信，丢给服务器端的 DataSetProvider，然后在服务器端，DataSetProvider 会将这个数据，变成 SQL 语句的 Update xxx 语句，实际去更改 DataBase Server 里面的 Data。这个过程完成后，客户端断开和服务器端的网路通信。这样就可以做到无状态，也可以做到服务器端只有10个实例在运行但可以同时服务200个客户端。

概念如此，但具体的技术实现上有一点不一样。简单说，如果用 COM Based，那么，你在客户端的 COMConnection 一旦 Connected = True 就是建立了和服务器端的网路通信连接。如果你不断开它，它就一直占用着。这时候服务器端就必须有一个 COM 或者 COM 的实例运行起来去服务器它。而这个 COM 的实例，可能会建立一个和 DataBase Server 的连接。如果你的前端程式一启动，就打开 COMConnection 的连接，一直到程式关闭，才关闭连接，那就不是前面说的无状态，关于3层的好处，也就享受不到。

如果是 WebService，基于 WEB 的原理，你每次访问，就是建立一个和 WEB SERVER 的 TCP 连接，访问结束，这个连接也就断开了。它天然是无状态的。你必须要自己写一些额外的代码来实现自己的需求，比如翻页（无状态模式下，千万不要写 select * from MyTable 这样的代码。有状态模式下，这样的代码没问题，数据库服务器也就是 DataBase Server 里面会有游标，它一次可能只丢出100条数据给你，你向下滚动的时候，它才继续丢数据给你，它在服务器端帮你维护了状态。无状态下，它会把里面的几十万条数据一次都丢给你，然后网路很慢，你就等死在那里了。）。


在 Web Service 模式下，一开始我按照李维的讲法，把 WebService 只当作一个薄中间层，它去向真正的中间层 COM 那一层取数据，由 COM 那一层去真正连接数据库。后来发现，让 WebService 直接连接数据库，在一些不是非常大的系统上面，也是可以的，问题不大。

WebService 底下，如果在服务器端直接嵌入 Indy THTTPServer，把服务器端直接做成一个普通的 EXE，它自己就包含了一个 WebServer，这样的方式，调试的时候非常方便。到 XE3 的时候， Indy 已经比较稳定，我对 TIdTCPServer 做过压力测试，发现并发2000个连接不停地连上，取数据，断开，这样连续跑几个小时，都没问题。因此，现在简单的应用，我都直接采用内嵌 IdHTTPServer 的方式。当然，对于复杂的应用，我会分两步：
第一步，将服务器端编译成 CGI 的方式给 IIS 调用。这样就算服务器端有 BUG 会导致内存泄漏或者出现AV错误等等，它不会将 IIS 搞死。一次访问失败后，不影响下次。
第二步，如果确认自己写的服务器端没问题，又想提高 Web Server 的效率，就把它编译成 ISAPI。不过 ISAPI 一但出问题，会把 IIS 搞死的。

OK，到这里，我自己的使用经验差不多了。

对于最新的 REST DATASANP，李维的书我也买了，还没时间仔细学习。不过我知道它和以前的架构的区别主要是：
1. 传输的数据封包，采用 JSON。在 Com Based 方式下，数据封包是 OleVariant，是符合 COM 协议的二进制包；在 WebService 底下，是 OleVariant 但这个 OleVariant 在网路上被编码成 XML。我觉得封包格式的区别，对于写CODE的人来说，关系不大。
2. COM 和 WebService 都是基于 Interface 编程的。这种模式非常好。而 REST DataSnap 变成了基于 Class/Object 的，我反倒觉得不太好。
3. REST DataSnap 主要是基于 IdTCPServer 的。这样，客户端和服务器端可以保持长连接，好处是服务器端可以回叫（CallBack）客户端，坏处是【无状态】这种编程模式，反倒可能就让初学者不容易掌握了。因为一旦保持客户端和服务器端的连接，则非常容易写成有状态方式。当然，有状态的方式，代码会少写很多。

以上三点，不一定对，因为我还没真正深入去使用 REST DataSnap。

>>真正要理解三层架构，一定要做到【无状态】（Staeless）。理解了【无状态】，也就不存在翻页的问题了 --- 翻页，应该是数据库 SQL 要解决的问题。

讚！理就是這個理！我最終也是把分頁功能交由 SQL 來處理，在中間層做分頁太不經濟了

謝謝 pcplayer99 大的心得分享！

 

一層非常好用，BDE的採用

 

新奇的技術 -- 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。

看到這裡，難免想到幾個東西:

1/ webbroker
2/ websnap
3/ intraweb (vcl for web)

這三個東西，就技術層面來看都有許多的共同性。有機會的話，想聽聽你實作上，或是經驗上的看法。若能簡介、比較一下，對這方面的初學者，或是delphi/cb新進人員應該會有不少幫助。我其實很不喜歡borland/embt 類似的東西用一堆"產品名詞"來包。經常的，從名詞上搞不懂它到底是什麼。 而首要的，初學者都需先知道，哪個是幹啥的… 這算是無謂的浪費時間。因為一行程式也沒寫就要先去查、去了解那些名詞含蓋哪些技術，能處理什麼事，甚至底層是什麼，而分別又是什麼…

有時間或有興趣再回。這是看到此刻我突發的一種想法。偏離主題就是了…

keep going :)

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

寫真多 真是熱血 
個人對Datasnap的看法是
如果是只有幾個使用者 必需要透過Internet存取 對穩定性要求不高 (可以忍受server常當機)
就很適合去使用


如果想做到無態 又想要有packrecords的效果 最好是放棄IProvider的介面
取資料 和存檔都是自己去呼叫遠端的methed
不過可能會遇到不少需要自己去解決的奇怪問題
比如
http://delphi.ktop.com.tw/board.php?cid=30&fid=66&tid=104565

去修改Clientdataset 的Source 會是比較直接簡單的方法

分頁也不一定要靠SQL來做 Select * FROM XXX 也行
DataSetProvider.GetRecords 可以往下取中第幾筆

要實做遠端的Function 就如同google Facebook 提供的API 一樣
RO 可能是個堪用的選擇

不過呢 看看外面一堆web service ,大部分都是Java做的 因為在Java的世界
做web service是相當容易的 並且是可大可小 全部都有現成的方案

Java當後端 win32 程式 , javascript ,mobile app 當前端 不限定語言平台當前端 一魚多吃

選擇開發工具是這樣 用開發效率來看
基本上往人多的地方靠攏就對了 因為大部分的問題 都已經有人解決了

當然 如果是對某種開發工具語言有偏好 那又是另當別論


===================引 用 GrandRURU 文 章===================
>>真正要理解三层架构，一定要做到【无状态】（Staeless）。理解了【无状态】，也就不存在翻页的问题了 --- 翻页，应该是数据库 SQL 要解决的问题。

讚！理就是這個理！我最終也是把分頁功能交由 SQL 來處理，在中間層做分頁太不經濟了

謝謝 pcplayer99 大的心得分享！