在資料庫操作時,面對多個操作的並行操作,為了避免資料不一致和衝突我們主要有兩種方法可以達成這個目標:樂觀鎖 (Optimistic Lock) 和悲觀鎖 (Pessimistic Lock)。但我們應該如何選擇適合的方法呢?
樂觀鎖和悲觀鎖的實作網路資源太多了,這篇不會特別提。
在資料庫操作時,面對多個操作的並行操作,為了避免資料不一致和衝突我們主要有兩種方法可以達成這個目標:樂觀鎖 (Optimistic Lock) 和悲觀鎖 (Pessimistic Lock)。但我們應該如何選擇適合的方法呢?
樂觀鎖和悲觀鎖的實作網路資源太多了,這篇不會特別提。
Dictionary<TKey, TValue>
是很常用的資料結構,我們可以使用索引子 (Indexer) 透過特定的 Key 來存取資料。 但使用時,我們要特別注意 Key 的型別,使用值型別作為 Key 通常不會有問題,但當使用參考型別作為 Key 時就不一定了。
在 C# 中,partial class 可以讓開發者把一個類別分散到多個檔案中。當程式編譯時,這些分散的部分會被合併成一個單一的類別。這篇會根據以往經驗來紀錄一下使用建議。
在開發過程中,我們經常需要透過 ORM (我是使用 EF Core) 從資料庫中取得資訊,在查詢很複雜的時候我通常都會盡量透過一個查詢就把資料準備好,並轉換成巢狀的資料結構以便於應用程式進行操作,這樣可以避免多次查詢造成的效能風險。
但前陣子在開發過程檢查 ORM 產生的 SQL 時意外發現我的認知不一定是對的。
Reference Source 是一個非常方便的資源可以用來查看 .NET Framework 的程式碼,而這個網站是利用 SourceBrowser 所建立的。
對於我們自己開發的專案,雖然都有原始碼好像用不到這個工具,但很多時候想快速查看程式碼卻又不想耗費資源在執行 IDE 上的時候(尤其同時維護多專案的時候),這個工具能提供一個不錯的介面來使用。
官方提供了基本的使用教學,但要開 Visual Studio 來編譯 SourceBrowser 專案,比較不方便,所以這邊會使用官方也有提供的 NuGet Package 來做,稍微紀錄一下過程,讓之後需要的時候能更快的使用。
當我們想要使用實作 IDisposable
的型別時,using
關鍵字通常是不二人選,但是其中卻包含一些小陷阱 (嚴格來說不是陷阱,是實作 IDisposable
的時候沒做好)。
背景知識:
using
關鍵字就是 try-finally 加上呼叫IDisposable.Dispose()
的語法糖,沒把握的話找個反組譯工具確認一下就知道了。
Hangfire 是很常用的定時排程工具,他會將排程和任務資訊紀錄在資料庫中,但是如果使用 Redis 做資料儲存時,就必須謹慎思考資料清理的問題,畢竟資料存放在記憶體中是不可能不去限制大小的。
很多時候我們需要從客戶端從透過 HTTP GET 發送 Reqeust 給服務端,但在之前的一個 ASP.NET Core 的專案中卻因為 Uri 過長而出現了 Invalid URI: The uri string is too long
這樣的錯誤訊息。
這個問題網路上幾乎都是改 Web Service (例如: IIS) 的設定來解決,這是最簡單方便的方法,但如果伺服器很多或是需要經常擴充伺服器時就會造成不小的困擾,即使伺服器不多也可能因為這些瑣碎的設定造成維護上的不方便,所以這邊提供另外一種解決方案。
擴充方法是很常用的技巧, 之前在使用 Entity Framework Core 的時候, 擴充了一個 IQueryable<T>
的擴充方法 WhereIf()
, 後來想說這個方法也適用於其他衍生自 IEnumerable<T>
的型別, 且 IQueryable<T>
繼承了 IEnumerable<T>
, 所以把 WhereIf()
方法改成 IEnumerable<T>
的擴充方法以求更廣的適用範圍, 沒想到一切都不一樣了, 要是當時沒及時發現就引爆了一個效能核彈了.
雖然標題是寫 Entity Framework Core, 但
IQueryable<T>
本來就是設計給”資料查詢”的情境來說, 其他 ORM 八九不離十會遇到一樣的現象.
使用 Windows 內建的遠端連線工具 (Remote Desktop Connection) 如果需要支援雙螢幕的話需要做一些設定,這些網路上資源很多沒什麼好說的。
但是如果是想要只使用三個螢幕中的其中兩個螢幕呢?