距離上次發文，已經過去了三年半，這幾年技術更新節奏異常迅猛，.Net進入了跨平臺時代，前端也被革命性的顛覆。

回顧

　　2015年，正當我還沉迷于JQuery + EasyUi的封裝時，突然意識到技術已經過時。

　　JQuery在面對更加復雜的UI需求時顯得力不從心，EasyUi雖然組件比較完善，但界面風格老舊，響應速度慢，且是收費商業產品，在一個商業產品上投入精力封裝并不劃算，所以我果斷棄坑了。

　　然后開始封裝JQuery + Bootstrap,在一個SPA（單頁應用）項目里暴露出很多問題，讓我認識到JQuery不適合做SPA，我開始尋找新的方案。

　　AngularJs(ng 1.x)是谷歌出品的JS框架，幾本書下肚以后，我開始琢磨著如何把AngularJs操作封裝起來，為了封裝成鏈式調用，甚至改了它的源碼以支持服務定位器模式。

　　正當我準備封裝基于AngularJs的UI組件時，發現它也過時了。由于UI封裝工作量巨大，而前端環境異常混亂，不再敢輕舉妄動，直到前端三大框架浮出水面。

　　2016年，.Net Core興起，為了方便學習交流，Alexinea（劉怡）發起了.Net Core學習小組，Kiler(謝煬)、Lemon(劉浩楊)和我做為第一批成員加入了小組。

　　微軟當時尚未提供.Net Core中文文檔，為了方便國內.Net Core的學習和推廣，.Net Core學習小組組織了一批.Net愛好者進行翻譯，直到官方提供了中文文檔為止。

　　2017年，.Net Core學習小組決定發布開源項目以推動.Net Core的發展，.Net Core學習小組也正式改名為.NET Core Community（.Net Core中國社區），簡稱NCC。

　　最初加入的項目有Lemon的AOP框架AspectCore，Savorboard（楊曉東）的分布式事務解決方案CAP框架，以及我的應用框架Util。隨后一些優秀的開源項目加入了NCC，包括爬蟲解決方案DotnetSpider，分布式微服務框架Surging等。

Util產生的背景

　　我長期混跡于小型軟件公司，小公司資源有限，人少事多，水平也參差不齊，如何降低團隊的學習成本，如何提高項目的開發進度，如何降低Bug率，是我的主要關注點。

　　Util應用框架是我在多年的項目實戰中積累起來以解決上述問題的利器，實踐證明，它在多個小型團隊和多個中小項目上起到關鍵作用，甚至包括一些瀕臨流產的項目。

中小項目的瓶頸在哪

　　對于中小項目，簡單CRUD（增刪改查）占據大量篇幅，核心模塊包含復雜業務邏輯，報表包含復雜查詢，另外還需要權限控制、流程控制等，不管模塊再多，大體不出這個范圍。　　

　　前端UI體驗變得越來越重要，工作量也越來越大。一個簡單CRUD，服務端API開發半小時，UI可能需要折騰一天。

如何打破瓶頸

　　如果能夠迅速拿下CRUD，并且能有效減輕前端開發任務，那么就能將更多精力投入核心業務，從而提高項目交付能力。

　　對于服務端CRUD，通過封裝基類再配合代碼生成就能很好解決，如何提升前端開發效率？

正確認識"前后分離"

　　一些人鼓吹“前后分離“原則，前端界面交給專業的前端人員，后端人員只負責提供API就好了，這似乎是提升前端開發效率的靈丹妙藥。

　　問題在于小公司資金預算有限，而專業前端人員薪資要求很高，以低價招聘的前端人員，往往只會HTML + CSS，JS耍得并不溜，最后還得服務端程序員上場。

　　另一方面，前端還有前臺和后臺之分，前臺是面向終端用戶的網站，比如門戶網站，商城一類，前臺偏重展示，規律性不強，后臺是面向用戶或管理員的表單系統，偏重功能，規律性比較強。大多公司的前端人員主要開發前臺網站，而管理后臺還是服務端程序員開發，前端人員頂多幫助界面布局，功能還是后端人員完成。

　　"前后分離"不一定是人員的分離，也不能降低工作量，主要是指前后端依賴關系的分離，如果前端技術或后端技術可隨意替換，而不是綁定在一起，就認為分離成功，這提升了項目的可維護性。

Js框架的選擇

　　為了降低前端開發難度，選擇一個好的Js框架顯得特別重要。

　　對于一個復雜界面操作，JQuery同樣可以完成任務，但與現代主流的Js框架相比，JQuery操作Dom的方式更加復雜，效率低下，且難以維護。

　　現代前端三大Js框架是Angular(ng 2+)，Vue和React。通過學習，發現Angular更符合我對開發效率的追求。

　　要提升開發效率，最關鍵的特性就是代碼提示。不相信？？請在記事本上用C#寫幾句試試。

　　Angular是谷歌開發的Js框架，默認采用Typescript(Ts)語言開發，Typescript是微軟開發的強類型腳本語言，它是Js的超集，在VS或VSCode上具有代碼提示。

　　你可能會說，Js不也有代碼提示？這完全不一樣，Ts具有強類型的代碼提示，你只能看見對象上明確定義的成員，提供了非常精確的提示，而Js的代碼提示滾動條好幾米長，和當前對象無關的信息也顯示出來，這嚴重降低了代碼提示的作用。

　　除了代碼提示，Ts還填平了Js固有的一些設計缺陷。

　　很多開發人員不選擇Angular的原因是需要多學一門腳本語言，認為成本高，這其實是一種誤解。

　　Ts在語法上有點像Js + C# + Java的混合體，對于C#或Java程序員，上手成本非常低，開發起來讓你爽不停。

　　作為微軟系.Net程序員的我們更應該大力支持。

聲明式編程

　　現在我們在開發服務端和前端腳本時都有了代碼提示，工作效率得到提升，還能更進一步嗎？

　　現代流行的前端框架都有組件或指令的概念，用來支持聲明式編程，它通過擴展Html自定義標簽或自定義屬性的方式來調用Js。

　　這種方式將Js隱藏在內部，將Js轉化成了Html，形成更好的封裝性。毫無疑問，使用Html編寫的頁面，比使用Js具有更強的表現力。

　　如果文本框需要非空驗證，只需要在標簽上加個屬性，就像下面這樣，你并不需要調用任何Js就完成了驗證工作，這相當酷。 

<input required=”true”>

 　　不過我發現很多團隊并不使用聲明式編程方式，更愿意使用Js，原因在于Html是弱類型標簽，自定義屬性并沒有代碼提示，這確實是個大問題。

TagHelper - 編寫Html的救命稻草

　　我在2012年學習Dwz這個前端框架時，接觸到聲明式編程的概念，也被Html無提示的問題所困擾，后面發現Asp.Net提供的HtmlHelper能夠封裝Html，提供強類型的代碼提示，這正是我需要的特性。

　　2015年用HtmlHelper封裝了EasyUi，雖然只完成了一些基礎工作，但使用過的人都認為它大量提升了開發效率，它現在甚至仍然是一些公司的主打技術。

　　HtmlHelper也有缺陷，它看上去是C#代碼，而不是標簽，比如HtmlHelper封裝的文本框長成這樣。

　　如果需要前端同學來幫助你調整界面，這就不太友好了。

　　另外HtmlHelper與Html混在一起也讓代碼看上去不直觀。

　　微軟發現了這個問題，在Asp.Net Core推出了TagHelper，TagHelper與HtmlHelper類似，也是用來封裝Html的強類型工具，不過它用起來是個標簽，如果你不注意，根本看不出這是Html，還是TagHelper，這對前后端人員配合完成Html頁面具有重大意義。

　　現在TagHelper封裝的文本框長成這樣了。 

TagHelper與Angular結合的艱難之路

　　使用Angular或Vue框架，你通常不會從0開始工作，尋找現成的UI組件庫是更明智的選擇，比如Angular可以選擇Angular Material或Ng-Zorro。

　　這些庫都提供了大量組件和屬性，如果直接使用Html編寫，沒有代碼提示，你必須隨時打開官網，四處翻上翻下以尋找你需要的屬性，哪怕你曾經用過它，如果你記得不是十分精確，從官網復制粘貼會時刻伴隨著你。

　　現在好了，你知道TagHelper是救命稻草，可能已經迫不急待想要動手封裝了，不就是把Html拼接出來輸出到頁面，這能有多難？別急，小伙子，將Angular組件封裝成TagHelper可不是你想的這么簡單。

　　如果你關注過Asp.Net Core Angular這個模板項目，你會發現這個模板使用的依然是Html，而不是TagHelper，這是為什么？自家這么好的技術，你都不推廣一下？

　　我憑借之前封裝HtmlHelper所積累下來的經驗，將Asp.Net Core 2.0 Angular這個模板項目改造成支持TagHelper，這是使用Angular提供的JIT編譯特性做到的。JIT就是即時編譯，會在運行時動態獲取Html頁面并編譯成內部Js，我在Github上也發現國外有些人在使用這種方式，不過都處于Demo級別。

　　我用TagHelper封裝了Angular Material組件庫，并將它應用在項目上。

　　很快爆發了嚴重的性能問題，這時候項目上的頁面也才上百個。

　　從啟動到看見登錄頁面，需要半分鐘，F5刷新還需要這么久，這個速度是無法接受的。

　　我觀察到系統在啟動時會請求所有頁面，原來我雖然使用了Angular模塊，但沒有使用延遲加載，主模塊直接引用了子模塊，導致在啟動時加載全部頁面。

　　使用延遲加載緩解了這個問題，啟動能在三秒左右完成，進入子模塊也需要幾秒，雖然能勉強使用，但性能和AOT編譯相去甚遠。

　　AOT編譯是Angular提供的預編譯，能在發布階段把Html文件直接編譯成Js，這樣在運行時就不再訪問Html頁面，對性能具有極大的提升。

　　使用了TagHelper以后，并沒有Html文件，AOT編譯無法訪問服務端Url，所以沒辦法使用。

　　魚和熊掌都想兼得，如果能夠得到TagHelper的編譯時檢查和代碼提示功能，又能得到AOT編譯的運行時性能，這該多好啊。

　　我當時寄希望于Asp.Net Core團隊，希望他們能提供一點支持，在Github提了Issue之后，Asp.Net Core團隊表示TagHelper與Angular這種Js框架水火不容，機制上的問題。我后面仔細想想，確實如此，TagHelper主要為服務端MVC提供支持，而使用了Angular這樣的Js框架后，路由都走客戶端，通過AOT編譯后，服務端除了提供WEB API，真沒它啥事。

　　由于TagHelper提高了我團隊的開發效率，延遲加載能讓這個機制勉強使用，我也就堅持了下來。直到有一天靈機一動，用TagHelper生成出Html文件不就好了嗎，和玄冰同學折騰了一天，終于解決了這個問題。現在，TagHelper充當了代碼生成器的角色，服務端MVC相關的特性被全部拋棄。

小結

　　前面介紹了Util的一些背景和動機，同時也解釋了為何我花大把時間在UI封裝的原因。

　　未完待續，下一篇介紹Util包含的主要功能，以及讓你把TagHelper + Angular Material封裝的Demo運行起來。

　　Util應用框架的下載地址為：https://github.com/dotnetcore/Util

　　寫文需要動力，請大家多多支持，點下推薦，Github點下星星。

　　Util應用框架交流一群: 24791014