距離上次發文，已經過去了三年半，這幾年技術更新節奏異常迅猛，.Net進入了跨平臺時代，前端也被革命性的顛覆。 回顧 2015年，正當我還沉迷於JQuery + EasyUi的封裝時，突然意識到技術已經過時。 JQuery在面對更加複雜的UI需求時顯得力不從心，EasyUi雖然組件比較完善，但界面風格 ...
距離上次發文，已經過去了三年半，這幾年技術更新節奏異常迅猛，.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
