前言:
有一次在記憶體snapshot中發現某個ClassName+<>c的物件,如下圖紅框處:
第一次看到有點不知所以,查了一下,這是compiler建立用來執行lambda的class。
To be continued...
參考資料:
https://blog.jetbrains.com/dotnet/2019/01/23/c-classes-memory-snapshots/
前言:
有一次在記憶體snapshot中發現某個ClassName+<>c的物件,如下圖紅框處:
第一次看到有點不知所以,查了一下,這是compiler建立用來執行lambda的class。
To be continued...
參考資料:
https://blog.jetbrains.com/dotnet/2019/01/23/c-classes-memory-snapshots/
Publisher物件可提供事件供其他subscriber物件做訂閱,且一般也會在適當的時機點取消訂閱,
但如果只訂閱但沒有取消訂閱,會讓程式memory leak嗎?
我將情境分為以下4種:
1. Publisher生命週期較subscriber長,subscriber有取消訂閱。
2. Publisher生命週期較subscriber長,subscriber沒有取消訂閱。
3. Publisher生命週期較subscriber短,subscriber有取消訂閱。
4. Publisher生命週期較subscriber短,subscriber沒有取消訂閱。
Subscriber使用下圖的Log類別,Log訂閱Server的ServerConnected事件:
以下依序列出測試結果,這裡使用VS內建的記憶體快照來確認物件是否已GC:
1. Publisher生命週期較subscriber長,subscriber有取消訂閱:
2. Publisher生命週期較subscriber長,subscriber沒有取消訂閱:
可以看到Log物件(subscriber)還存在記憶體。3. Publisher生命週期較subscriber短,subscriber有取消訂閱:
4. Publisher生命週期較subscriber短,subscriber沒有取消訂閱:
情境3跟4,都是Server物件先回收,Log物件還留著的情形,記憶體快照也是一樣結果,前言:
最近遇到一個情境,物件的某個event trigger會多次,
但訂閱的event handler method只需要處理該event trigger的第一次,
該怎麼做呢?
作法:
如下圖的Document類別,有一個Loaded事件,當呼叫Open方法時會觸發Loaded事件。
前言:
提到資料庫存取,大多會擔心撰寫的statement是否有效能問題,
雖然公司可能會有DBA來review開發人員的statement,
但開發人員仍需初步判斷所寫的statement執行的狀況。
以SQL Server來說,會使用SSMS(SQL Server Management Studio)裡的執行計畫(Execution plan)來判斷。
作法:
可以準備幾個要比較statement來跑執行計畫,一般會先看是否有吃到index,
效能通常是:index seek > index scan
但如果SELECT的資料筆數接近整張table的筆數,SQL Server就可能採table scan將資料回傳。
基本上使用PK來當條件,就會套用cluster index seek。cluster index預設是從table的PK建出來的,每張table只會有一組,如下圖OrderID是[Orders]的唯一PK。
to be continued...
參考資料:
https://docs.microsoft.com/zh-tw/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver15
https://docs.microsoft.com/zh-tw/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described?view=sql-server-ver15
https://github.com/Microsoft/sql-server-samples/tree/master/samples/databases/northwind-pubs
前陣子開發電子化表單相關的程式,剛好使用到狀態模式(State Pattern)。
需求是每張表單有其狀態,每個狀態有對應的處理動作,
因此直覺上可以使用狀態模式的概念來處理。
先上個類別圖:
這邊使用抽象類別StateBase,下方的類別就是實際的狀態,
以請假表單來說,會有初始狀態與主管審核後狀態,
Execute方法代表執行狀態對應的動作,可能是狀態移轉或通知對應的人。
而StateContext是管理狀態的類別,其Request方法呼叫state物件的Execute方法,
並注入執行的state instance,以提供狀態執行所需的環境資訊。
剛好這需求,一開始同事是使用switch case來處理各狀態行為,
我改成狀態模式,避免全部的狀態行為都擠在同一個方法,
後續擴充維護也會容易許多,這也是Open–closed principle的精神。
Authorization Code是OAuth的其中一種授權方式,
可以讓client程式取得使用者(resource owner)外部的資源,需要使用者輸入帳密,
流程如下:
● 觸發驗證流程後,client程式將使用者的瀏覽器導向authorization server的驗證端點(authorize endpoint)。
● 此時網頁會顯示client程式想存取使用者在外部的哪些資源,等待使用者授權。
● authorization server依使用者回應與帳密決定是否授權。
● client程式再帶authorization code、redirection URI等參數POST到authorization server的權杖端點(token endpoint)。
● authorization server確認參數無誤後,即回傳access token相關資訊,即可以此token跟resource server要資料。
以Flow chart描述流程如下:
來個實際操作吧,這邊使用Google OAuth來取得userinfo:
https://accounts.google.com/o/oauth2/v2/auth?
client_id=client id from google oauth setting&
redirect_uri=redirect_uri from google oauth setting&
response_type=code&
scope=profile&
access_type=offline&
state=up to you
參考資料:
https://tools.ietf.org/html/rfc6749
https://developers.google.com/identity/protocols/oauth2/web-server