大匠之風

2020/01/17

【前端】實戰 ASP.NET C# 移轉到 REACT 01

緣起

之前使用 ASP.NET C# WebForm 寫一套公司內部的報修系統，如下圖所示。
但維護上：

遇到 JavaScript Callback hell
在後端上想整合為一套語言，把 Server side 轉到 Client side (後台不需要考慮 SEO 問題)
前端以JavaScript為核心，CSS 就依賴 3rd party 輔助開發。
這個專案非常小，很適合拿來練手。

在 React 使用 Font Awesome

在【[Day 09 - 網速換算器] 網速傻傻分不清楚 Mbps? Mb/s? 來寫個單位換算器吧】
這篇看到 REACT 搭配 Font Awesome 的畫面後，想試試看是否能在REACT專案中也套入它的效果。

因為REACT網站不能夠像範例那樣直接使用HTML引入的手法，所以就用正規的import方式來使用。

認識 Delphi Community Edition (CE) 版本

【RAD Studio】=【Delphi】+【C++ Builder】

在認識Delphi CE之前，就不得不提一下Delphi在我心中到底是個什麼樣的存在。

從前從前，在我很小的時候，學習過Visual Basic、PowerBuilder、Foxpro、MS Access和JAVA等語言，每一項至少學習三個月以上。

單機資料庫連結方式如何選擇，以SQLite為例

在描述選擇Delphi CE有什麼優缺點後，接下來就是要如何選擇資料庫的連結技術。

目前Delphi CE提供了ADO、dbExpress（DBX）和FireDAC資料庫連結技術，ADO它沒有壞掉，效能也好，在沒有跨平台需求用它就可以了。

DBX和FireDAC，這個比較難選，先來看看它們的差異：

單機版最常用的兩款資料庫：Access和SQLite在FireDAC上都有提供，但DBX只提供SQLite的連結方式。

而SQLite和MS Access相比下又有幾個優點：

小巧輕巧
速度快
跨平台

以實際操作來比較DBX和FireDAC的差別。

首先利用自己做的Dbexpress.SQLite.Factory建立資料庫和資料表格：

建立比操作輕鬆太多。（笑）

使用DBX連結資料表：

從Palette容器裡拖拉一個TSQLConnection到TForm中，並且設定好SQLite的連線參數。
從Palette容器裡拖拉一個TSQLDataSet到TForm中，在CommandText屬性輸入『SELECT * FROM biolife』。
對TSQLDataSet按右鍵，選『Fields Editor』，並對跳出的編輯器按右鍵，選『Add all fields』

上述步驟完成後，會得到以下結果：

    SQLDataSet1species_no: TWideMemoField;
    SQLDataSet1category: TWideMemoField;
    SQLDataSet1common_name: TWideMemoField;
    SQLDataSet1species_name: TWideMemoField;
    SQLDataSet1length_cm: TWideMemoField;
    SQLDataSet1length_in: TWideMemoField;
    SQLDataSet1notes: TWideMemoField;
    SQLDataSet1graphic: TWideMemoField;

表格內有 real, text, blob 型別，但轉換後全是 TWideMemoField，有點奇怪，來看看FireDAC會不會有所變化。

使用FireDAC連結資料表：

從Palette容器裡拖拉一個TFDPhysSQLiteDriverLink到TForm中。
從Palette容器裡拖拉一個TFDConnection到TForm中，並且設定好SQLite的連線參數。
從Palette容器裡拖拉一個TFDQuery到TForm中，在SQL屬性輸入『SELECT * FROM biolife』。
對TFDQuery按右鍵，選『Fields Editor』，並對跳出的編輯器按右鍵，選『Add all fields』

上述步驟完成後，會得到以下結果：

    FDQuery1species_no: TFloatField;
    FDQuery1category: TWideMemoField;
    FDQuery1common_name: TWideMemoField;
    FDQuery1species_name: TWideMemoField;
    FDQuery1length_cm: TFloatField;
    FDQuery1length_in: TFloatField;
    FDQuery1notes: TWideMemoField;
    FDQuery1graphic: TBlobField;

FireDAC可以正確的取得SQLite資料表各欄位格式。

結論

由上面的資料顯示，若使用SQLite單機資料庫，會是以FireDAC表現會比較好。

DBX Driver官方目前已不會有大幅度的功能更新，所以SQLite控制上不會比FireDAC來得好，建議有使用SQLite需求，應採用FireDAC。

2019/10/23

DBX Error: Driver could not be properly initialized in SQL SERVER

"DBX Error: Driver could not be properly initialized. Client library may be missing, not installed properly, of the wrong version, or the driver may be missing from the system path."

測試專案時並沒有遇到這類的問題，但在WebBroker專案下會出現這樣的 Error。

除了安裝 sqlncli.msi 是必須的之外，由於 DataSnap / WebBroker ：

早期的MSSQL driver使用COM
框架使用到 Thread

所以【CoInitialize / CoUninitialize】的呼叫也是必要的。

但這錯誤訊息完全無法看出端倪，故記錄在此。

題外話，新版的 MSSQL 為了跨平台，也開始使用ODBC連接，沒了COM，自然也就不用 CoInitialize / CoUninitialize，ODBC for DBX也許就可以拿來用了呢！（笑）

See also

2019/10/09

TIdHTTPWebBrokerBridge and HTTPS

為了提高網路傳輸的安全性，許多前端套件都開始強制要求使用HTTPS連線才能操作。

然而這在Delphi DataSnap / WebBroker server Debug很是困難，因為預設沒有 HTTPS。

自XE2版後，DataSnap精靈也可以看到HTTPS的選項。

但下一頁的憑證要求應該讓不少人傻眼吧。

文件裡寫的資料不多，很多OpenSSL的小技巧需要留意。

實作的程式碼就是 Indy HTTP SERVER + SSL，第一次看到實作碼時還不自覺地笑噴。

江湖一點訣啊！

結語

經實驗證明可以使用，但因為舊版 Indy 不支援 TLS1.1 以上加密等級，所以Browser會加上【弱加密】警告標語，請留意 Indy 使用版本。

See also :

2019/10/02

TIdHTTPWebBrokerBridge效能和驗證(Authorization)

圖／取自網路

TIdHTTPWebBrokerBridge 目前會用到的地方大概只有 Stand-Alone 場合，更偏向於 Debug 應用。

看到 Marco 寫的 Thread Pooling 文章，不太能夠理解只是Debug為什麼還需要這麼大的效能。

Thread Pooling

Marco原文是這樣說的：

Regarding threading, creating one for each incoming request is Indy’s IdHTTPServer default configuration, but you can tune it adding code to the server main form, which creates and manages the Web server component.

大意上是說每個Client都會建立一條Thread，所以用了Thread Pooling後可以預先把Thread開好，就不用花時間在每次連接的Thread建立時間。

另一個好處是：限制Client數上限(MaxConnections)，總比Server崩潰要好一點。

使用它不吃虧，就記錄一下要怎麼用吧！