(NEW)EFCORE效能
https://blog.darkthread.net/blog/ef-core-test-with-in-memory-db單純 CRUD 用 EF (或自製 ORM) 享受強型別保護及不沾 SQL 的清爽,至於複雜查詢、批次更新刪除,則回歸自己寫 SQL 以確保執行效能。
案例 1. 叫用 csp 時
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475 public virtual async Task<List<csp_GetPromotionEngineSpecialPriceDataResult>> csp_GetPromotionEngineSpecialPriceDataAsync(string queryType, string salePageIds, string skuIds, string pro ...
(NEW)EFCORE效能
https://blog.darkthread.net/blog/prevent-aspnet-session-timeout/
AutoMapper
organic and gluten-free ?
最近,對研發工具有些興趣。在眾多工具中,AutoMapper 作為研究對象。儘管我對它的了解還停留在一知半解的階段,但我決定以此為切入點,探索「使用工具」這個主題背後的含義。
通過研究 AutoMapper,我開始思考:一個好的工具應該具備哪些特質?它如何影響我們的工作方式和思維模式?在軟體開發中,我們應該如何權衡使用現成工具和自行開發之間的利弊?
自訂轉換邏輯例如在 DB 我們有這個 Model
12345678910111213public class CountryProfile{ public long CountryProfile_Id { get; set; } public string CountryProfile_Code { get; set; } public string CountryProfile_Name { get; set; } public string CountryProfile_EnglishName { get ...
Stripe
The Payment Intents APIPayment Intents API 是 Stripe 提供的一個用於處理複雜支付流程的工具。思考:為什麼需要一個專門的 API 來處理支付流程?傳統的支付處理方式有什麼局限性?
主要功能:
處理變化的支付狀態追蹤整個支付生命週期在需要時觸發額外的認證步驟
思考:這些功能如何提高支付流程的可靠性和安全性?
優勢:
自動處理認證避免重複收費解決冪等性問題支持強客戶認證(SCA)
思考:這些優勢如何簡化開發流程?它們如何影響用戶體驗?
應用場景:
每個 PaymentIntent 通常對應一個購物車或客戶會話
思考:這種對應關係如何幫助管理複雜的電子商務場景?
123456curl https://api.stripe.com/v1/payment_intents \ -u "{YOUR_STRIPE_TEST_SECRET_KEY}:" \ -d amount=1099 \ -d currency=usd
Passing the client secret to the client sid ...
HttpContext 失效時,我們還能說什麼
那是一個午後,城市被陽光輕輕包裹著。我走過熟悉的街口,沒有目的地,只是順著記憶走。
咖啡廳的窗戶閃著熟悉的光,我下意識地望進去 —— 她,就坐在靠窗的位置。那個多年不見的身影,仍舊筆挺,肩上落著光,就像記憶裡的那樣。
我愣了一下,彷彿穿越了幾年的時間。當正要推開門的時候,門內走來一名男子,笑著坐在她對面,手中拿著兩杯咖啡。
她抬頭接過咖啡,對他微笑,那笑容熟悉卻已不再屬於你。
片刻後,一個小男孩蹦蹦跳跳地衝進店裡,喊著「爸爸!」男人張開手臂將他抱起,她則伸手輕拍孩子的頭髮。
你靜靜地站在門外,手輕輕從門把上放下。你沒有走進去,也沒有發出聲音。因為你知道,那個 context,早已不在了。
你轉身離開,步伐輕而穩,那封從未送出的請求,就此作廢。
愛必須在對的 context 中發送。
...
Data Validation
[ApiController]Data AnnotationsFluentValidationsummary
[ApiController] 這個 Attribute 會幫 ASP.NET Core Web API 預先接手一部分「參數綁定」和「資料驗證」的工作,讓 Controller 更像在專心處理業務邏輯,而不是一直重複寫防呆判斷。
進來的 Request 先做參數來源判斷,ASP.NET Core 會先看 Action 參數的型別,推測資料應該從哪裡來
複雜型別,通常從 Request Body 取值
IFormFile 或 IFormFileCollection,通常從 Form Data 取值,上傳檔案時,前端通常會送 multipart/form-data。[ApiController] 看到參數型別是 IFormFile 或 IFormFileCollection,就知道這不是一般 JSON,而是表單資料
簡單型別或其他一般參數,通常從 Query String 取值
框架自動做 Model Binding,也就是把 HTTP Request 裡的 ...
Enumerator
🍔 從 foreach 官方文件開始想要使用 foreach 的集合需要實作 System.Collections.IEnumerable or System.Collections.Generic.IEnumerable interface
foreach 的真正實現,是一個迴圈控制結構,必須知道:
怎麼取得下一筆資料 (MoveNext)
怎麼拿到目前這筆資料 (Current)
怎麼從頭開始 (GetEnumerator)
這一切都來自於 Iterator 模式,也就是 .NET 中 IEnumerable / IEnumerator 的設計核心。
🍔 有一天我在摩斯排隊點餐,但前面點餐的大叔點有點久,於是我開始發白日夢…一位客人
1234567public class FatLaw{ public int Number {get;set;} public string [] Menu {get;set;}}
排隊點餐的一群客人
123456789101112131415161718192021 ...
Anti Join
雞巴人NOT INNOT EXISTSLEFTJOIN... IS NULLEXCEPT測試方法你曾經鼓起勇氣,傳訊息給喜歡的人,卻始終只收到那令人心碎的「已讀不回」?你也曾在朋友聚會中,主動張羅大小事,結果現場只來了一半,還都最後才現身?
你就是個魯蛇
這背後有「資料科學」的真相,就是所謂的隱藏多數
全部的人 - 出現的人 = 雞巴人
今天,我不想再假裝一切都沒發生。我要來製作一張黑名單,把這些嘴上說愛你、行動卻放你鴿子的人,通通揪出來!
手上有兩份資料:
Friends(朋友名單):那些理論上應該會出現的傢伙
Attendance(實際到場名單):那些真的有出現、值得你好好珍惜的朋友
接下來,我們要開始用幾個方法,來抓出那些含糊不清的嘴砲王
「拿一個主表的鍵,去跟一張子查詢產生的名單比對,只留下『不在名單裡』的那些資料」
123SELECT FriendID, FriendNameFROM FriendsWHERE FriendID NOT IN (SELECT FriendID FR ...
Pre Aggregation
關於曉關於資料庫tempTable 拆查詢summary曉組織從不會跑去逐村、逐個忍者詢問「你是不是叛忍」,那樣太慢
他們先整理來自各村的大量任務紀錄,任務失敗率、行蹤中斷、查克拉特徵異常、忍術使用頻率…把整個忍界的龐大資料先「彙整」出一小群行為模式明顯脫離正常範圍的忍者。
等到名單縮小之後,曉組織才拿這份「疑似叛忍清單」去比對外部情報:黑市名冊、走私紀錄、賞金通緝、各村密報……這就像 JOIN 小表。
先把大集合縮到只剩「關鍵群體」,外部情報才能精準派上用場;不然會浪費巨大成本也找不到目標
不好的處理方式假如有以下資料
表格
筆數
說明
a
1,300,000 筆
主資料表,存放每筆紀錄(包含 name、bid、cid、did、count、position)
b
5 筆
小表,包含欄位 col1
c
5 筆
小表,包含欄位 col2
d
5 筆
小表,包含欄位 col3
需求是針對每一組 (a.name, a.bid, a.cid, a.did),計算 SUM(count) 與 AVG(position),並且 JOIN b、c、d 取出對應的欄位 col ...
STRING_AGG
一生中有三大難題🧪 實戰💩🐛 結語☘️ 人的一生中有三大難題:
中午吃什麼?
明天要不要請假?
怎麼把一堆資料拼成一句話?
前兩個我還在想,第三個已經找到解答了—— STRING_AGG
他常用來作為文字串接的聚合函數,官方定義是這樣子的 :用於把 “指定的欄位” 串成一個 “以指定分隔符分隔的字符串”,不用寫一堆複雜的迴圈或自製拼接邏輯
123456STRING_AGG ( expression, separator ) [ <order_clause> ]<order_clause> ::= WITHIN GROUP ( ORDER BY <order_by_expression_list> [ ASC | DESC ] )
每天上班打開公司群組,就像打開一個沒人整理過的資料表,一堆廢話、貼圖、+1、讚、下午茶,語焉不詳的訊息而零散像剛剛爆炸過。有時真的很想把他們 STRING_AGG 起來丟到任何看不見的地方「那個誰,幫我把這個資料表裡的這些串在一起」光頭手上揮舞著資料像在招魂一樣,語音剛落
123 ...












