程式開發一段時間,對於序列化各個眉角,沒碰過一萬應該也有一千(誤),累積了不少經驗;
應該大部分情境也都能分出注意事項,逢凶化吉~,但這次dynamic 情境算是上了一課,
凡事還是小心為妙,別一昧的依賴經驗。在開始說明前先對於 dynamic 整理一點點資訊。
程式開發一段時間,對於序列化各個眉角,沒碰過一萬應該也有一千(誤),累積了不少經驗;
應該大部分情境也都能分出注意事項,逢凶化吉~,但這次dynamic 情境算是上了一課,
凡事還是小心為妙,別一昧的依賴經驗。在開始說明前先對於 dynamic 整理一點點資訊。
又往前推進了一個版本,這次來到 C# 7.3 ,而這小改版有一個地方讓我非常有感,
那就是「泛型的條件約束」,所以來特別來介紹,以前在設計泛型的時候,很常使用到「列舉」
,但就是無法直接使用關鍵字 Enum,需要轉念一下,原來是要使用 struct 關鍵字...
這篇名字有點長,這是無意間發現的狀況,好奇心作祟筆記一下;實務上不可能將既有運作中的資料
表隨意的轉換型別,更不用說兩者類型所儲存的內容天差地遠,轉換也沒意義;
踩到這系列的雷,以往都是看別人解決,終於發生在自己身上,順手紀錄一下;
情境是抓了某個版控的專案,一抓下來,執行build就炸掉...
我認為單元測試主要用來驗證程式設計邏輯與系統功能正常運作的技法,期望哪些情境下,確保我們的設計都有考量到,
並且滿足需求,另外再未來擴充與修改系統功能下,依然能 維持既有的測試案例(不會改東壞西),
增加對軟體的信心度。但,再開始之前,
這個語法之前一直沒有相對必要的實際應用,若真需要列表分群,覺得使用表格呈現較好閱讀,但若僅是單純的文字
表達作為備註欄位,覺得是個不錯的解法...
Reflection 很常使用,雖不是專案標配,但一年之內總會有使用它的地方,實務上往往與多型搭配起來完成動態實例化物件的技法;
但現實中既有程式難以捉摸,不一致的撰寫風格,或意指相同事務,但文字與設計方式卻充滿弔詭。這次遇上了,
還好C# 內建函式可以幫忙解決。
GitHub Gist 是github 的子服務,可以用來分享簡單的檔案內容(一至多個),同樣支援公開或私有的分享層級;檔案有提供嵌入連結,所以有人拿來當部落格的資源存放。
使用t-sql 實作分頁也算顯學,使用CTE (後續也打算補上筆記) 搭配OFFSET 與FETCH NEXT,
也算是手到擒來,但若Sql Server 屬於滿清時代的 2008 以下版本,就需要另外語法,
這邊展示一下。