demoshop

最近因為一些原因，加快了我把某專案升級為 .NET 6 的時程，升級之前當然是要做些 POC 最簡單的就是建立一個範本專案，然後跑一些重點需求，確保這些需求的執行結果如預期，而在開啟範本專案後，有一個東西吸引了我的眼球，如是我就開始研究進去了…            

先說結論：這是編碼錯誤導致！

印象中每一版的 Visual Studio 剛推出都會有一樣的問題（難怪大家都說不要裝中文版），昨天要睡覺之前寫好了一個新功能，推上 Azure DevOps 跑到 CI 時一直跳出 Error CS1010: Newline in constant 的錯誤， 一時半刻沒反應過來，一陣子後才回想起這不是每次都會碰到的嗎….（上一次是 2019 難怪我忘了） ，這篇文章會快速的講原因和解法。 

Link Tag Helper 是在 .NET Core 的 MVC 與 Razor Pages 中提供的新擴充方法，用來處理使用 CDN 載入外部資源時的例外處理，可以用很優雅的方式設定外部資源載入錯誤時的備援機制，以往在 .NET Core 2.x 的時候專案範本擁有完整的範例，但升級到 3.x 後此範例就沒了，所以這篇文章主要就是記錄官方內建的範例程式碼，也順便釐清問題。

廣大的 .NET 開發者一定都用過 DateTime ，取得現在的時間就很自然的使用 DateTime.Now，看似美好的日子竟然會因為雲端的普及而開始受到迫害，雲端平台的服務因為是全球性質因此時區通常都定在國際標準時間 UTC +0（以下稱為 Universal Time） ，所以為了時區的正確性，我們開始改變了時間的寫法，由 DateTime.Now 換成了 DateTime.UtcNow ，並且保持一個開發原則，進資料庫儲存的都是 Universal Time 顯示時再調整為適合的本地時區（以下稱為 Local Time 並且使用台灣時區 UTC+8）顯示，在這個原則限制之下世界終於恢復了平靜，但真的是這樣嗎？…

相信很多人是直接跳這裡看結論的，但我真的希望你結論看完以後回頭看看其他兩篇的文字與範例程式碼，你應該更可以感受到 Razor Pages 的優良之處，我現在一個專案開始的時候我會優先選擇使用  Razor Pages ， 除非我在初期就明確的知道這個專案在 MVC 會比較好寫，這兩者也不應該是堅持一種，應該看專案的不同與專案成員的能力來選擇，只會一種你就沒得選，會兩種你的機會就大，我們有在開設 Razor Pages 的課程，歡迎你來加大自己的版圖，讓你也有[選]的能力。

精準解析 RazorPages
https://skilltr.ee/razorpage            

以前 MVC 框架有人反應拆太細了，大多數專案其實不需要那麼龐大的架構，現在有了更聚焦更輕量化的 Razor Pages，或許對於我們是一個不錯的解法。

情境解說

在資料庫中的資料表欄位會依據資料面來設計，但往往會與「顯示」「新增」「編輯」時所需的欄位不同，可能有多也可能有少，得過且過的開發人員會一股腦的都用 DB Model 來傳遞資料，但這是一種浪費也可能造成資安問題，依據我們開發 MVC 的習慣會建立稱為 View Model 的傳遞物件，本篇文章就來示範此情境在 ASP.NET MVC 與 Razor Pages 我們會怎麼做。

為了讓範例可以達到不用解釋的目的，我們將以會員註冊這大家都寫過的東西來做範例。

 身為講者與愛分享的我，一直以來都有這樣的需求，之前是使用「擴充套件」來滿足，現在內建功能已經可以辦到了，來看看如何啟用吧。

首先我是有在玩遊戲的，所以有安裝雷電模擬器，而這模擬器會在開啟的時候提示玩家是否有開啟虛擬化技術（VT），最近新買電腦，第一次開啟雷電模擬器時看到了 VT 沒有正確啟用的警告，上網搜尋了許久看了一堆問答，最後終於在官方文件找到調整方式，也更進一步的找到 GUI 的設定方式，所以特別記錄一下。

從 .NET Framework 時代的 ASP.NET MVC 就有內建防範 CSRF 的機制，這機制在 MVC 架構下開發者可自由的選擇啟用或關閉，但是 .NET Core 發行時新推出的 RazorPage 則是預設開啟了 CSRF 防範機制，現在的網路環境越來越危險了預設開啟是非常正確的選擇，但是這樣的預設啟用對於初級的開發者來說就會很挫折，為什麼一個 AJAX 都寫不好呢。

雖然說官方文件都有，但開發人員不看文件的比例和不寫文件差不多，所以我還是寫一篇來記錄一下吧

在 RazorPage 中一個頁面（功能）需要的是多個集合的物件那就這一頁的 PageModel 自己建立就好，回想一下寫 MVC 的時候是不是會有一堆只用一次的 ViewModel ，一個物件只使用一次不是問題，問題在於很多功能很類似的 ViewModel 命名上是相當困難的，為了要明確的識別每一個 ViewModel 所以命名就會越來越長，到最後就難以維護。

RazorPage 資料傳遞的類別都會包在自己身上，對於前後端需要並行開發的專案來說會比 MVC 更簡單一點，開發過程中的調整也都不用擔心會有人共用，造成改A錯B的窘境，直接改就可以也再次呼應了上一篇講的，如果你的專案在開發的時候還不知道最後到底要做什麼，還沒有規劃完善那 RazorPage 會是你更好的選擇。

對於 RazorPage 開發有興趣的朋友可以參考 SkillTree 的課程😎