.Net Core應用框架Util介紹（一）轉

回顧

　　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就完成了驗證工做，這至關酷。 

1	< 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點下星星。