前幾天處理了一個檔案沒更新的問題,請看下圖:
這是一個 UNC 路徑,可以看到它路徑中間有兩個 \
,然後它就爆了。
會造成這樣的原因是因為在原始程式碼中,在兜路徑的時候沒有處理尾綴的 \
的數量,而使得尾綴的 \
多了或少了,路徑就失效了。
前幾天處理了一個檔案沒更新的問題,請看下圖:
這是一個 UNC 路徑,可以看到它路徑中間有兩個 \
,然後它就爆了。
會造成這樣的原因是因為在原始程式碼中,在兜路徑的時候沒有處理尾綴的 \
的數量,而使得尾綴的 \
多了或少了,路徑就失效了。
這個雷我踩了不下三次,寫下來記錄一下,C# 程式要取得當前目錄的方法我們下關鍵字搜尋可以搜出一堆解決方案,沒意外的話第一個搜尋結果通常是 Directory.GetCurrentDirectory 方法(System.IO) - MSDN - Microsoft,但是這個方法在程式是由 Windows 工作排程器(Task Scheduler)啟動的狀況下就不 Work 了。
TaskCompletionSource 這個玩意兒是我在 InAppBillingPlugin 這個 GitHub 儲存庫發現的,查了一下 MSDN 它說「代表未與委派繫結之 Task<TResult> 的生產者端,可提供透過 Task 屬性對消費者端的存取。」?????? 它在說什麼?我們來舉個例子。
Task 是從 .NET 4.0 開始就有的東西,用它來取代傳統的 Thread、ThreadPool 還挺便捷的,但有時候有一些有時效性的 Task,當它執行超過我們規定的時間時我們需要知道,Task.Wait()
可以帶入 millisecondsTimeout
參數,不過它是同步的。
有這個議題是既有系統的 Cache 邏輯在 Cache 沒有命中的時候,會啟動 lock 機制,然後去執行一個由呼叫端傳進來的 delegate function 去後端資料庫重新取得資料,可是我們都知道每家公司多多少少都有遺留一些「初學者程式碼」,這些初學者程式碼不一定是初學者寫的,但它有時候執行的效能並不是很好,在這種情況再搭配 lock 機制之下,後面進來的 Request 就塞住了,進而影響客戶端的響應速度。
關聯式資料庫的資料都是以表格型式呈現為主,而物件導向世界的資料型式是階層式的,面對這兩種資料呈現的型式,程式設計師在資料表的設計上著實燒腦,過去很多教授 ADO.NET 的書籍範例只會教用 DataSet、DataTable、SqlDataReader 來處理從資料庫取得的資料,如果我們直接照著用,當所面臨的需求不再如同書本範例簡單的時候,程式寫起來挺痛苦的,而我們也沒辦法享受到物件導向設計帶給我們的好處,如果我們在工作上還是需要自己下 SQL 語句,Dapper 會是我們的好幫手。
在設計中加入 AOP 著實會讓程式碼清晰度大增,讓程式的職責更清楚,Autofac 中的擴充套件 Autofac.Extras.DynamicProxy 可以輕鬆地讓我們實現 AOP 的功能,在註冊完後可以呼叫 EnableInterfaceInterceptors()
或 EnableClassInterceptors()
的其中一個方法來啟用 Interceptors,而這兩個擴充方法的區別又在哪?
今天以前,我一直以為「在 C# 程式裡面只要是 String 型態,其內容都會在 String Pool 有一份,而且相同的 String 實體物件在記憶體中只會有一份。」,這個觀念在今天得到了修正:「只有在編譯時期的 Literal String,預設才會放進 String Pool,執行時期動態組成的 String 物件則不會。」,再次命中了「程式是照我們寫的跑,不是照我們想的跑。」
天有不測風雲,人有旦夕禍福;服務在走,HA 要有,先前有介紹過使用 Redis-Sentinel 打造 Redis 的 HA,當時只完成了伺服器端的設定,這次要介紹如何在應用程式這一端也完成自動 failover,以維持服務的 HA。
有時候我們會有這樣的需求,我們需要取得相對於當前所在目錄的祖父兄弟目錄(暫且稱呼為叔公目錄)的絕對路徑,如果我們已經知道叔公目錄的絕對路徑永遠不變,當然就直接 Hard Code 取用就好,但是這種狀況是少之又少,大多數情況是整個家族目錄會因需要而搬家,在已知叔公目錄名稱的條件下,要得知叔公目錄的絕對路徑,我們可以這樣做,找到曾祖父目錄之後,把叔公目錄名稱合併在後面就可以了,而我們要怎麼用 C# 找到曾祖父目錄呢?