軟體主廚的程式料理廚房

如果我們希望為 Elasticsearch 加上登入的身份驗證，透過帳號密碼來控制存取服務的權限的話，有一個 Plugin 可以用 - Shield，裝起來之後不用做太多設定它就能運作了，而且還可以做 IP 的過濾、整合 AD，如果角色不夠用還可以自訂角色，做更彈性的權限控制。

ELK（Elasticsearch + Logstash + Kibana） 是這兩三年來很火紅的日誌收集分析平台，尤其是 Logstash 的部分，提供了各式各樣的日誌收集及輸出的 Plugin，搭配 Elasticsearch 這種分散的索引搜尋系統，收集日誌只是一塊蛋糕而已，如果你有收集大量日誌的需求可以考慮用 ELK，畢竟 Splunk 很貴啊啊啊！

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

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

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

在[料理佳餚] Entity Framework Code First 不算太難用這篇有講到要使用 Code First 不難，難的地方是不要讓 Entity Framework 拿我們設計出來的 Model 去建出低效的資料表。

要避免 Entity Framework Code First 建出低效資料表，了解 TPH、TPT、TPC 這三種資料表被建立的方式是必須要做的功課之一。

Entity Framework（本篇討論的是 6.x 版本）基本上有 3 種 ORM 的方式：Database First、Model First、Code First。

一般人對 Code First 的恐懼是它必須透過程式碼來控制 Table Schema、Field Attribute…等來完成資料庫的設計，比起用 SSMS 透過 GUI 來操作顯得不是很方便。