軟體主廚的程式料理廚房

之前在[料理佳餚] 使用 Decorator Pattern 分離參數檢查與資料處理這篇文章有提到我想要用 AOP 的方式來把參數的條件檢查分離出來，當時還沒有什麼好的做法，但是在遇到 FluentValidation 之後有了新的想法，只要搭配 Autofac 及 Autofac.Extras.DynamicProxy2 就可以實現參數條件檢查的 AOP 攔截器。

先前在[料理佳餚] 使用 Decorator Pattern 分離參數檢查與資料處理這篇文章裡分享過如何分離參數的條件檢查及資料處理的邏輯，讓程式碼的職責可以更聚焦，不過那篇文章裡面參數檢查條件的範例部分是單純用 if...else... 兜出來的，看起來有點「阿雜」。

有一個 Package 叫 FluentValidation，它可以將單純用 if...else... 兜出來的參數檢查條件，用口語化的方式來表達，讓程式碼可以更貼進人的閱讀習慣。

軟體開發的過程當中，針對傳遞進方法中的參數避免不了一定要做一些像是邊界值、限定值、特殊值…等一堆你想得到的檢查，如果我們把條件檢查跟資料處理放在同一個程式碼區塊，同一區塊的程式碼長度就會增長，自然就會降低閱讀的順暢度。

我也想過用 AOP 的方式來解決，但是沒有想出來一個比較好的設計去處理不同的參數個數、不同的參數型態，以及要檢查的邏輯，想來想去 Decorator Pattern 雖然會多出一些類別，但能做好「關注點分離」，這一點點的 effort 是可以接受的。

被問到「你能不能講一下什麼是 C# 中的泛型？」，這個時候我突然覺得泛型離我好遠、好遠…，明明平常用很多，常常見面啊！為什麼現在講不出來！？ Orz…

原來我平常只懂得用，其實對於它的定義、限制不是很了解，稱得上是不學無術，今天被問到這個問題算是有一個機會可以讓我了解「泛型」這個好朋友，特此記錄，以示提醒。

「你如何預防 SQL Injection？」這個問題已經成為了一個顯學，現在我們寫程式如果沒有把解決 SQL Injection 的方式變成習慣，我們就絕對是個不及格的程式設計師，一個領域如果夠成熟，那這個領域會累積一定厚度的必學項目，像 SQL Injection 的問題就是累積來的，面試也常常會問。

之前有介紹過[料理佳餚] C# StackExchange.Redis 使用 Redis Message Broker 服務，StackExchange.Redis 稍嫌美中不足，以目前來講 Failover 要自己控制，當然自己控制是沒有什麼問題的，不過既然有其他工具可以幫我們 handle 這一切，當然就讓工具來協助我們。

曾經的一個需求，需要在 Client 端對位於檔案伺服器上的檔案進行操作時，切換到另一個具有權限的 Domain 身分，只用過這一次，分享給大家參考。

DES 加密演算法是一種對稱加密演算法，但是用來加解密的 Key 及 IV 需要固定長度，DES 的 Key 及 IV 長度大小都是固定 8 bytes，也就是說每次加解密的過程中都需要湊足 8 bytes 的 Key 及 IV，多了或少了都不行。

我參考余小章的文章 - [C#.NET] 字串及檔案 利用 DES / AES 演算法加解密，實作如何使用不固定長度的 Key 及 IV 進行 DES 加解密。

NEST 的 Search 方法直接將搜尋結果轉換成強型別來提供給我們使用，可說是非常方便，那我們能不能將搜尋結果轉成另外一個強型別呢？答案是肯定的，不過如果直接將 Search 這個一般化方法指定的類別給換掉，會踩到一些雷，且看接下來的說明。

要在 Elasticsearch 下達搜尋指令找出一些東西來，可以透過像 kopf 這類的 Plugin 所提供的 GUI 來直接操作 Elasticsearch 的 RESTFUL Api，可是我們最終還是有需要自己寫程式來下搜尋指令的時候，除了用像 RestSharp 這類的套件，再自行轉換 JSON 結果之外，當然也可以透過 NEST 來輕鬆達成。