全國最多中醫師線上諮詢網站-台灣中醫網
發文 回覆 瀏覽次數:16896
推到 Plurk!
推到 Facebook!
[<<] [1] [2] [>>]

我的中間層開發,我的 DataSnap

 
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#1 引用回覆 回覆 發表時間:2015-02-08 08:22:59 IP:211.79.xxx.xxx 訂閱
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 ,這個理由也依然適用。
編輯記錄
GrandRURU 重新編輯於 2015-02-08 08:26:29, 註解 無‧
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#2 引用回覆 回覆 發表時間:2015-02-08 15:20:12 IP:114.32.xxx.xxx 訂閱
等你下集 ^^
------



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

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#3 引用回覆 回覆 發表時間:2015-02-09 17:31:51 IP:59.120.xxx.xxx 訂閱
多層,究竟有幾層?試著定義一下。

一層:
如果沒有使用到資料庫,那一定是「一層架構」,所有的操作全在使用者的電腦上完成,大都利用序列化陣列來當作資料庫也就足夠滿足需求。
※Delphi.KTOP 的資深版主 Jason Wang 表示:
「dBase、Foxpro 等這類的檔案型資料庫也屬於一層架構的一種。」
所以可以說,沒有內建 Service 的資料庫服務,都稱得上是一層架構。


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



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

絕大多數的開發者在這個階段,因為對三層的設計方式不熟悉,以及文件資訊不足的惡劣條件下毅然地放棄對 DataSnap 的使用,退守回兩層的開發,這實在是很可惜的事情。

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

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

設計前的彈性很足,但框架定義完卻很難修改,所以大型專案必須經過長時間的規畫及時間來鑽研系統的穩定性。

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

換句話說,就是現在網頁設計規範所提的「前端技術」和「後端技術」

前端:
泛指使用者能夠輕易看到的視覺變化技術。(例如:HTML5、JavaScript 和 CSS)

後端:
使用者看不到的繁瑣處理機制。(例如: PHP、ASP.NET 等)

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

多層的架構牽涉的面向太廣大了,所以之後的重心還是放在三層 / 前中後端的內容上。

--- 未完待續 ---
編輯記錄
GrandRURU 重新編輯於 2015-02-10 10:57:52, 註解 無‧
GrandRURU 重新編輯於 2015-02-10 10:59:21, 註解 無‧
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#4 引用回覆 回覆 發表時間:2015-02-11 00:33:37 IP:211.79.xxx.xxx 訂閱

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 遠端桌面連線的雙保險機制同時被使用,提供給開發人員作為參考。










--- 未完待續 ---
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#5 引用回覆 回覆 發表時間:2015-02-11 11:09:42 IP:59.120.xxx.xxx 訂閱
 DataSnap 如何能解決兩層開發的問題?
1. 提供 HTTP / HTTPS 及 TCP/IP 兩種通協定,並且可以自定封包格式內容,被破解機率在這一關就大幅下降,等同 VPN 的防護機制。

2. 資料庫連線數問題,連線數太多會造成資料庫效能降低;但太少時所花在連線交握的時間也不會讓使用端占上太多便宜。這部份的微調可視實際場合使用「連接池」( Connection Pool )來降低連線消耗。

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

只是 DataSnap 要做到上述的功能,大都需要自己額外寫程式,看到這裡想打退堂鼓的人應該不少。

按照 DataSnap 歷史路線來看,想要省力開發也不是沒有方法,RemObject Data Abstract 就是其中一個很好的合作伙伴。
RO DataSnap Server 端設計畫面。圖片來源:RemObjects

所謂的歷史路線指的是:Borland 一直到現在的 Embarcadero 本身沒有足夠的資源可以完善 DataSnap Server 端,所以讓 3rd-Party 廠商來合作完善,各位可以驗證看看現在的路線是不是依然使用合作策略方式。

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







--- 未完待續 ---
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#6 引用回覆 回覆 發表時間:2015-02-11 17:49:44 IP:59.120.xxx.xxx 訂閱
 

決定 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

--- 未完待續 ---
編輯記錄
GrandRURU 重新編輯於 2015-02-12 10:18:33, 註解 無‧
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#7 引用回覆 回覆 發表時間:2015-02-12 03:56:06 IP:220.129.xxx.xxx 訂閱
讚喔! 這算是 the old new thing :) 舊友新知 都值得看。 keep going!
------



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

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#8 引用回覆 回覆 發表時間:2015-02-12 09:58:17 IP:59.120.xxx.xxx 訂閱
謝謝蕭大的支持!

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

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


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#9 引用回覆 回覆 發表時間:2015-02-12 09:58:50 IP:59.120.xxx.xxx 訂閱
 

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

既然要把 Database 連接元件抽離,就免不了還要重新決定哪一種連線方法。

當然如果已經有喜好的連接元件,也是可以直接使用,並不是說 DataSnap Service 就必須採用特定元件。

Delphi / C Builder 提供了以下元件:
BDE 元件盤
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,必須再重新思考這四大元件的選擇。

--- 未完待續 ---
P.D.
版主


發表:571
回覆:3880
積分:3666
註冊:2006-10-31

發送簡訊給我
#10 引用回覆 回覆 發表時間:2015-02-12 23:55:46 IP:118.160.xxx.xxx 未訂閱
感謝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種就萬無一失, 可惜這方面對我來說不是專精的項目, 所以課程中還是有很多懵懵懂懂的章節, 加上公司業務繁忙, 課後也沒有太多時間可以進行了解, 如果在這方面有深入研究的網友願意分享那就更好了
編輯記錄
P.D. 重新編輯於 2015-02-12 23:57:07, 註解 無‧
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#11 引用回覆 回覆 發表時間:2015-02-13 08:58:58 IP:59.120.xxx.xxx 訂閱
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種就萬無一失, 可惜這方面對我來說不是專精的項目, 所以課程中還是有很多懵懵懂懂的章節, 加上公司業務繁忙, 課後也沒有太多時間可以進行了解, 如果在這方面有深入研究的網友願意分享那就更好了
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#12 引用回覆 回覆 發表時間:2015-02-13 15:25:50 IP:59.120.xxx.xxx 訂閱
 

DataSnap 有狀態( Stateful )開發研討

做為一個簡單易用的 DataSnap,書上的範例是這麼寫的:

基於 COM 架構:
DataSnap COM-Base 設計架構


基於 RESTful 架構
DataSnap RESTful-Base 設計架構


咦?好像差不多?
因為實在太像了,所以好像沒什麼變化,坊間有提到 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 的傳輸效能還有再往上的空間,在實戰上也確實是慢得讓我被使用者駡到臭頭。

--- 未完待續 ---
P.D.
版主


發表:571
回覆:3880
積分:3666
註冊:2006-10-31

發送簡訊給我
#13 引用回覆 回覆 發表時間:2015-02-13 15:37:41 IP:118.160.xxx.xxx 未訂閱
WebBroker 開發出來是 dll 的模式, 可供 Web 來呼叫, 也算是比較輕量型的 DataSnap, 它的效能是比較高的, 
但的確, 如果連線人數衝不到臨界點, 我覺得使用第1種也是足夠的(我是這麼認為)
目前的開發也還是使用 DataSnap Server 為基礎, 預計年後就要發表給客戶使用, 到時就可以得到一些數據了
===================引 用 GrandRURU 文 章===================
WebBroker?
我真的是忘記它了,當時在研究 REST DataSnap 還有向李維老師請教這兩者的不同。
李老師的說法是:
DataSnap Server 是提供一般應用程式形態的DataSnap伺機器,
DataSnap Rest Appliation是為DataSnap伺機器加入REST的功能, 可執行在Web Server中
DataSnap WebBroker Application是為WebBroker技術加入DataSnap功能,
主要目的應該是為了把早期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種就萬無一失, 可惜這方面對我來說不是專精的項目, 所以課程中還是有很多懵懵懂懂的章節, 加上公司業務繁忙, 課後也沒有太多時間可以進行了解, 如果在這方面有深入研究的網友願意分享那就更好了
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#14 引用回覆 回覆 發表時間:2015-02-14 08:59:02 IP:211.79.xxx.xxx 訂閱

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 來說只能是一種奢求。


--- 未完待續 ---
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#15 引用回覆 回覆 發表時間:2015-02-16 10:42:02 IP:59.120.xxx.xxx 訂閱
 

我的 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:利用公開的函式庫,下載所需要的物件,再另行處理。


--- 未完待續 ---
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#16 引用回覆 回覆 發表時間:2015-02-21 07:57:10 IP:220.134.xxx.xxx 訂閱
以下是我整理的主題方向

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

結語

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

只是不曉得大家有沒有興趣就是了,哈哈
編輯記錄
GrandRURU 重新編輯於 2015-02-21 08:09:06, 註解 無‧
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#17 引用回覆 回覆 發表時間:2015-02-23 11:09:33 IP:114.32.xxx.xxx 訂閱
非常的好!  建議寫的時候就用一些排版軟體寫好再來貼文。因為…這麼多的內容,相當於一本書了。在你貼完的同時,我想可以拿去順便出版,qcom是個出版的選擇,因為他們曾提過。一魚二吃!

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

期待你的作品。 ^_^


------



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

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan
pcplayer99
尊榮會員


發表:142
回覆:737
積分:590
註冊:2003-01-21

發送簡訊給我
#18 引用回覆 回覆 發表時間:2015-02-26 11:20:17 IP:120.236.xxx.xxx 訂閱
写得非常好!


我补充一点点:

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

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。
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#19 引用回覆 回覆 發表時間:2015-02-26 14:15:50 IP:59.120.xxx.xxx 訂閱
>>真正要理解三层架构,一定要做到【无状态】(Staeless)。理解了【无状态】,也就不存在翻页的问题了 --- 翻页,应该是数据库 SQL 要解决的问题。

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

謝謝 pcplayer99 大的心得分享!
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#20 引用回覆 回覆 發表時間:2015-03-02 17:20:22 IP:59.120.xxx.xxx 訂閱
 

一層非常好用,BDE的採用

在剛接觸C Builder時,大部份時間都在連接埠的輸出、輸入外,接著就要把資料儲存,以便後續的報表輸出,當時最簡單使用的就是Paradox,手冊和範例最多,於是就用它了。

那Access怎麼不考慮?

因為公司沒買。(冷)

好吧,接著便是發展所謂單機版的資料庫應用程式,話雖如此,也是過了一年的快樂時光。

那時最常使用的工具--Database Desktop


Database Desktop、BDE、PX、DB、Repair Paradox Tables等,我想有接觸過的開發者就不用多談,還沒用過的,應該也不需要再用它了。
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#21 引用回覆 回覆 發表時間:2015-03-02 17:20:49 IP:59.120.xxx.xxx 訂閱
 

新奇的技術 -- dbExpress

在 Paradox 玩了一段時間之後,便開始挑戰大系統的實作,接著便入手了這本書--「C Builder資料庫程式設計-人事薪資系統實作」
C Builder 資料庫程式設計 人事薪資系統實作 陳惟彬著
開始了解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」
BCB6也支援的dbExpress Driver 圖片來源: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也能搭配得相當愉快。
Interbase V6.0資料庫 圖片來源:Borland

在練習一陣子後,意外地發現有個可以替代Paradox,而且還能商業應用的資料庫服務:Firebird,更重要的是,dbExpress Driver是針對Firebird孿生兄弟--Interbase V6.0而設計,對於Firebird也發揮了百分之百的相容性。
Firebird資料庫 圖片來源:Firebird官方網站

了解Firebird和Interbase的關係後,便花了好長一段時間在BDE轉化為DBX的資料連結元件上,了解到更換升級並不是想像中這麼困難。

而關鍵的TClientDataSet也能順利和其它三方元件(如:QuickReport、Indy等)一同工作,在這個階段也算是我在DataSnap上完成了初步學習,只是當時還是傻傻地不明白為什麼寫個程式原來是這樣麻煩的道理。

就在整個專案導入了dbExpress之後,卻發生了下一件事情。



「客戶想要Web版。」
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#22 引用回覆 回覆 發表時間:2015-03-03 22:49:38 IP:221.120.xxx.xxx 訂閱

客戶的要求,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。
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#23 引用回覆 回覆 發表時間:2015-03-04 00:08:20 IP:114.32.xxx.xxx 訂閱
看到這裡,難免想到幾個東西:

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
leveon
資深會員


發表:29
回覆:386
積分:303
註冊:2012-02-12

發送簡訊給我
#24 引用回覆 回覆 發表時間:2015-03-04 11:54:04 IP:36.226.xxx.xxx 訂閱
寫真多 真是熱血 
個人對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 大的心得分享!
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#25 引用回覆 回覆 發表時間:2015-03-04 12:02:38 IP:59.120.xxx.xxx 訂閱
 
WebBroker, Internet Express, WebSnap and IntraWeb concept


有時間再個別解釋。
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#26 引用回覆 回覆 發表時間:2015-03-04 15:03:36 IP:59.120.xxx.xxx 訂閱
對Delphi開發工具還有一點小執念,就稍微做一下開發經驗回顧。

Java的WebService,應該可以考慮看看。
C# .NET的開發人士也很多

只是這兩個開發工具我還沒辦法掌握,還在熟悉中。

謝謝Leveon大的經驗分享!




===================引 用 leveon 文 章===================
寫真多 真是熱血
個人對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
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#27 引用回覆 回覆 發表時間:2015-03-05 11:31:50 IP:59.120.xxx.xxx 訂閱
 

該放棄Web還是C Builder?

回補一下關於Delphi/C Builder在Web上的開發方案,我整理了以下的簡圖:
WebBroker, Internet Express, WebSnap and IntraWeb concept


不論是WebBroker、Internet Express還是WebSnap,最大的問題在於「HTML、CSS、JavaScript」等Browser Client的糾結。對於已經習慣VCL元件的開發者,勢必又是另一個頭痛的戰場。

直接看一下沒有HTML和CSS概念下,所產出畫面:
Internet Express能提供標準HTML標籤
再來看現在新版JQuery UI基本款可以做到什麼樣的畫面:
JQuery UI提供的GridView 圖片來源:Jquerygridview.com
雖說美感是見人見智,但大多數人應不滿意標準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要來得好一點。
2014蔚為流行的瀏覽器綁架事件之一 圖片來源:Google 圖片

但事實上,如果Web安全性這麼高,就不需要防毒軟體存在。

從瀏覽器被綁架的事件滋生不斷中就可以得出,Web安全性也有它的漏洞存在。

被封裝好的執行檔(EXE)就一定不安全嗎?

在人手一機,還必備防毒軟體的現況下,執行檔有個什麼閃失就容易被防毒軟體抓去「收容」,執行檔就必不安全?

執行檔還有另一問題,就是部署了。

Inno Setup、InstallAware和InstallShield等都是解決部署問題的方法。

那麼執行檔變Portable(免安裝)化不可以嗎?

要讓使用者享受物聯網服務,就只有Web可以選擇?

說穿了,最終就只是載具問題罷了。

那穿透網際網路,執行檔直接穿透網際網路連接資料庫,光是安全性話題就足夠戰好幾回合,在這邊就不表了。

而C Builder有什麼可以跨網際網路的資料連結方案?

現成的概念就是MIDAS--分散式應用系統。




於是我就擁抱Delphi了。
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#28 引用回覆 回覆 發表時間:2015-03-05 12:55:18 IP:114.32.xxx.xxx 訂閱

>>而C Builder有什麼可以跨網際網路的資料連結方案?

>>現成的概念就是MIDAS--分散式應用系統。

>>於是我就擁抱Delphi了。


上面的「因為」、「所以」我不太明白。 我的意思是,想要 midas,也是可以c builder,必竟都是同 framework 。 於是你的 c builder ……… 我就擁抱delphi 了。 這個因與果應該有細節吧?!
------



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

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#29 引用回覆 回覆 發表時間:2015-03-05 14:08:51 IP:59.120.xxx.xxx 訂閱
Delphi比C++ Builder多太多DataSnap資料,研究到後來乾脆Delphi直上,所以就把C++ Builder晾在一邊啦。

久而久之,C Builder也忘得寫不出來……啊啊,只剩下LOGO可以追憶了!

比起這個,我更想知道現在還有多少人想開發DataSnap方案?



===================引 用 aftcast 文 章===================

>>而C Builder有什麼可以跨網際網路的資料連結方案?

>>現成的概念就是MIDAS--分散式應用系統。

>>於是我就擁抱Delphi了。


上面的「因為」、「所以」我不太明白。 我的意思是,想要 midas,也是可以c builder,必竟都是同 framework 。 於是你的 c builder ……… 我就擁抱delphi 了。 這個因與果應該有細節吧?!
編輯記錄
GrandRURU 重新編輯於 2015-03-05 14:14:31, 註解 無‧
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#30 引用回覆 回覆 發表時間:2015-03-08 22:49:10 IP:111.235.xxx.xxx 訂閱

現在是開發兩層還是三層?

dbExpress的開發畫面大概是這個樣子:


DataSnap的開發畫面大概是這個樣子:
Server端設計畫面
Client端設計畫面

好像有點一樣,又好像有點不一樣。
如果dbExpress改一下,就變成下面的畫面:
增加建立一個DataModule放dbExpress元件

ClientDataSet還在原來的位置,只是ProviderName會是DataModule.DataSetProvider1
相較之下,dbExpress好像只差了一個TDCOMConnection元件外,和DataSnap長相簡直一模一樣。

也難怪dbExpress要被人說閒話了,這複雜難用的神馬東西。

說易用沒有BDE來得自動化:TQuery TUpdateSQL,BDE小小調整一下,收工。
說功能沒有ADO來得全面:光是ADOConnection的Properties內容就可以談上十餘頁A4紙;ADOQuery幾乎把BDE元件所有功能包完。

反觀dbExpress,Driver Params就只有幾項,光產出的元件就比BDE多,程式的所有細節居然還全都要人工硬嗑,就算不寫程式碼,需要看的資料也絕對不下於ADO。

那dbExpress的架構到底是什麼?Borland開發這個是拿磚頭砸自己的腳嗎?(是的,它是)


用到現在,我終於參悟了dbExpress到底是什麼,算得上是三層嗎?



如果只能用一句話來描述dbExpress的層數,那我想我會說:





「兩層以上,三層未滿」(友達以上,戀人未滿)
GrandRURU
站務副站長


發表:234
回覆:1651
積分:1742
註冊:2005-06-21

發送簡訊給我
#31 引用回覆 回覆 發表時間:2015-03-09 14:41:18 IP:59.120.xxx.xxx 訂閱
 

ADO 是個好東西,不用嗎?

ADO--ActiveX Data Object
在RAD Studio裡被歸類在「ADO Express」元件盤中,RAD Studio 2006後則改名為「dbGo」。

ADO架構 圖片來源:MSDN Microsoft Data Development Technologies: Past, Present, and Future
ADO的缺點在於,全世界的作業系統中,只有Windows才有具備Ole Provider。
[<<] [1] [2] [>>]
系統時間:2017-10-18 4:43:30
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!