北京
用過ASP.NET Razor Pages的開發者，多半對那種頁面與模型清晰分工的寫法印象深刻。但你有沒有想過，如果把背后的模板語言換成設計更安全、對非開發人員更友好的Liquid，會是一種怎樣的體驗？
Kinetq開源的LiquidPages，就是這樣一個C#庫。它將Razor Pages式的MVVM理念帶到了Liquid模板體系中，并且不挑Web服務器——無論是EmbedIO、自定義HTTP監聽，還是其他能遞進請求的服務，它都能輕松接入。
在模板安全這件事上，LiquidPages選擇了一條很務實的路線。底層依賴Fluid庫來解析和渲染Liquid模板，而Liquid本身出自Shopify之手，沙箱化的設計讓它天然適合承載可能脫離源碼管理、由設計師或運營人員直接編輯的內容。
框架的結構理解起來并不復雜。每個頁面綁定一個頁面模型，模型在渲染時向Liquid模板提供強類型的視圖數據。換句話說，“.liquid文件負責呈現，C#頁面模型負責數據與邏輯”——這一套分工，和Razor Pages幾乎是同一個思路。
除了模板安全與熟悉的開發模式，還有幾個設計值得關注。首先，模板文件可以分布在解決方案里的任意C#項目中，來源可以是物理文件、嵌入資源，或者復合文件提供器，部署靈活度相當高。其次，框架本身以中間件形式出現，內置了針對EmbedIO的現成模塊，如果想接別的服務器，自己寫一個也不會太費事。
上手流程被刻意壓得很短。裝好Kinetq.LiquidPages的NuGet包，在依賴注入容器里調用“services.AddLiquidPages()”注冊服務，然后為所選Web服務器配好中間件，準備工作就基本完成了。
真正讓這一切跑起來的關鍵，是啟動階段的路由與過濾器注冊。應用需要注入ILiquidStartup接口，在啟動過程中依次調用RegisterPageModels和RegisterFilters兩個方法，框架才能知道該處理哪些路由、用哪些類型來承接請求。
當請求進來之后，中間件層面的ILiquidResponseMiddleware就接手了。它接收一個封裝了路由、查詢參數、請求頭和請求體的LiquidRequestModel，在已注冊的路由集合中逐一匹配請求路徑，找到對應規則后就渲染對應頁面，最終輸出一個可直接寫回響應流的LiquidResponseModel。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
