其實WebAPI在設定URL包含多國語系並不難，可以很簡單的在Attribute routing的URL Template中多一個Culture的參數即可。但是，如此一來，就必須在全部的Attribute routing都加上這一個參數，這在開發與維護上都相當的不變，所以希望通過自訂DefaultDirectRouteProvider來替所有的Attribute routing加上Culture參數。另外，URL上的語系並不定存在，當URL上沒有存在語系時，則使用預設語系，這也可以透過DefaultDirectRouteProvider一起處理。
在上一篇 Hello WebAPI中，已經介紹了如何使用 Visual Studio 2015建立 .Net Core WebAPI的專案，並且使用 Self-Host運行在本機上，接著將繼續介紹如何透過 EntityFramework.Core 1.0.0來存取資料庫。
.Net Core終於在美國時間6月27號 Release 1.0.0版，從第一次發表跨平台的 Framework到 Release的6月27號也歷經的一年多的時間，而在這一次的 Release中 Web的部分包含了 MVC和 WebAPI兩個部分，接下來的文章將會說明如何使用 .Net Core來開發 WebAPI。
目前，越來越多人選擇將系統建置在雲端的環境上，已取得較佳的水平擴展來應付高流量的情境。然而，在雲端的環境下AP Server很容易達成水平擴展，但是在資料庫的部分，卻還是還難實現水平擴展。其原因有，資料同步的即時性以及資料庫資源的昂貴，這兩項限制，讓我們不得不小心地使用資料庫資源。但是，在目前廣泛使用ORM Framework的情況下，工程師很容易不注意踩到ORM的效能地雷，其中一項就是著名的 "Select N+1"。這是一項既普遍又嚴重的地雷，當 "Select N+1"發生的時候，就等同於系統在DDOS系統自己的資料庫，造成效能不彰即費用增加。那這麼嚴重的問題該如何預防呢?很簡單，寫個測試來預防 "Select N+1"不就好了嗎。
DevOps的領域未來越夯，持續整合也越來越被許多團隊所重視。而在持續整合的過程中，自動化測試也是團隊在開發上很重要的一道流程。此外，在持續整合的過程中，自動化產生Live doucment也是很重要的。Live document由CI server根據BDD的測試案例自動化產生，可以避免系統功能改變了，系統文件卻沒有跟著修正的問題。
本篇文章將說明如何使用Jenkins建置並設定CI server，並且讓CI Server上的Job可以從抓取得程式碼、編譯、自動化測試、產生報表、發佈報表，所有動作只需要一鍵完成。
在上一篇文章中，介紹了如何使用Pickles將Feature的Test case自動轉成Live document。這樣的方式雖然已經能夠很方便，很快速的產出Live document，但是每次還是需要"人"來執行轉換指令，還是需要浪費到人的時間。那該如何讓Featurec和Live document的轉換變成自動化呢?
當團隊開始將需求規格實例化(Specification by Example)後，產出的Cucumber文件不單單只是可以拿來執行測試，還可以是讓整個團隊了解需求規格的文件。將需求規格文件與測試案例整合的好處，就是不用一份工作做兩次，寫一次文件後，在很多地方都可以拿來使用。除此之外，當需求有變化時，為了讓修改的功能測試可以通過，勢必會修改測試案例，讓測試能夠順利通過。透過這樣的方式，每次利用測試案例所產出來的文件也會跟著更新，這份文件就像有生命一樣會一直跟著系統功能與測試案例修改而更新，所以這樣的文件也可以稱為「Live Document」。
在上一篇文章(使用Asp.Net MVC 動態產生View Part.2 - 使用IViewEngine、IView)中，利用了IViewEngine, IView完成了動態頁面的產生。然而，動態產生頁面的功能是非常需要在每次上版前執行測試，這樣的功能當出現bug時，在第一時間就會被使用者發現，所以必須確保每次上版時，動態產生頁面的功能是正確的。
在上一篇文章中使用了VirtualPathProvider來完成產生動態頁面的功能，但是這樣的方法卻相當不容易進行測試。為甚麼說不容易進行測試呢?在使用自定義的CustomVirtualPathProvider時，需要在Global.asax中Application_Start方法將自定義的CustomVirtualPathProvider註冊到HostingEnvironment中，讓自定義的CustomVirtualPathProvider變成全域VirtualPathProvider。
現在的網站，越來越講求個人的客製化。不管是產生給個人用的Blog網站服務或者是電商平台上的商店，都希望讓個人或商店能夠有自己特有的頁面設計，在視覺上做出與其他人的差異化。如此一來，就需要為每個人客製化Asp.Net MVC中的View。但是，不管是個人的Blog網站服務或是電商平台都不可能為每個使用者客製化頁面。況且，就算是可以幫使用者客製化頁面，假設電商平台上擁有一萬家店，每家店有兩個Page是可以客製化，那就會多出39996個View file，這是一件多麼恐怖的事情，先不提如何更新，光是管理就夠讓人頭痛了。
在某個工作中，需要在一個Request進到Action前攔下來做一些前置的邏輯判斷，直覺地想到應該就寫個CustomActionFilter就搞定收工，結果當Filter寫完要放置到流程中的時候發現，哎呀，系統已經存在不少ActionFilter，那我放進去的CustomActionFilter會在哪個階段執行咧?
前幾天看到好友阿努的點部落PO了一篇文章，是關於使用Sandcastle Help File Builder 產生 .NET Library 說明文件。後來，有人討論說不知道能不能不需要自己手動加入Sandcastle專案，而自己也覺得Sandcastle不應該加入版控，但又想要有自動化產生文件的功能在CI上，所以就想辦法實作了一下。
因為久久要寫一個泛型的Expression Tree時，都需要找滿久的資料，以及花不少時間看懂微軟的範例程式，所以乾脆自己紀錄一下。
在某些情境下或是需要註冊的類別太多時，會使用Autofac的Module來封裝註冊資訊，將相關的類別註冊寫在同一個Module裡
Autofac在使用上有許多需要注意的小細節，這一次遇到建構式的小地雷，特別紀錄一下。讓下一次在踩到時，可以快速地排除。
當在類別中有使用到Autofac ILifetimeScope時需要特別注意建構式參數。一般來說，如果有需要在類別中使用ILifetimeScope，會在類別建構式中將ILifetimeScope注入
物件的繼承、介面這些知識就像線上遊戲剛創建帳號時，系統會自動帶著玩家完成一些事項和基礎技能點擊。換句話說，繼承、介面對於Coding Online的玩家是很基本、重要的。當然，物件的封裝、多型也是相當重要，但不在此討論，各位玩家務必要好好學習。
Coding Online技能攻略，對於每個Coder時間都是很寶貴的，當點擊了不適當的點數是沒辦反透過重置來取回時間，所以如何點擊技能樹是相當重要的。
