.Net Core应用框架Util介绍（四）
上篇介紹了Util Angular Demo的目錄結構和運行機制，本文介紹Util封裝Angular的基本手法及背后的動機。
Angular應用由Ts和Html兩部分構成，本文介紹第一部分。
Angular Ts的封裝
Ts是Angular的代碼部分，用于編寫頁面邏輯。
依賴注入( Dependency Injection )
Ioc(Inversion of Control)已經成為.Net Core服務端編程的標配，Ioc解耦了類和依賴類之間的創建關系，讓你開發出低耦合高內聚的系統。
有了Ioc，你就可以面向抽象編程，注入依賴的接口，直接使用即可，而不用關心這個對象是如何創建出來的，也不用關心它具體是什么類型。
Angular革命性的把Ioc引入到客戶端腳本編程，從這里也可以看出，Angular實際上更適合具有服務端編程經驗的開發人員。
依賴注入是Ioc的一種使用模式，最常見的是構造方法依賴注入，將依賴對象定義在構造方法參數上，運行時，Ioc框架會把依賴對象“推送”進來，從使用的角度看，業務代碼并不知道Ioc的存在，業務代碼未與Ioc框架耦合，極易測試，代碼也極度清爽，這一度讓依賴注入成為Ioc的代名詞，也是Ioc的推薦用法。
當在Angular中使用依賴注入，有沒有什么缺陷呢？下面來看個例子。
?
這段代碼需要發送Http請求，所以從構造方法注入了Http。
你必須要精確的知道Angular的哪個類提供了Http服務，并且需要知道這個類在什么路徑下。并不是每個類都像Http這么簡短易記，這增加了大腦的負荷。
對于專業Angular前端人員，這算不上什么缺陷，不過它確實增加了小團隊使用Angular的學習成本。
對于這個例子，哪怕你知道注入Http類，也清楚它的路徑，但可能仍然引入了未知的Bug。Angular還提供了一個叫HttpClient的類，它在@angular/common/http路徑下，HttpClient提供了攔截等高級機制，用來取代@angular/http包。如果你團隊的一部分人使用HttpClient，并對Http進行了攔截，比如設置全局Token，另一部分人使用Http類發送請求，就會導致潛在的BUG。
現在你清楚了對Angular API進行封裝的必要性。
封裝是一種隱藏實現細節的手段，封裝以后，你的注意力將從Angular Api轉移到自己的業務上。
對于Http請求，理想的API可能長成這樣。?
?
首先，你并沒有從@angular/common/http引入HttpClient，更沒有在構造方法上注入它。這解決了需要記憶API的問題。
其次，你并不清楚util.http封裝的具體類型是什么，這統一了團隊的API調用，也方便你在未來需要更換實現時不至于挨處查找。
我在前幾年使用EasyUi時也封裝了這樣的Helper，通過直接引用并簡單包裝就完成了任務。?
Helper往往表現為靜態方法，面對Angular的Ioc體系，封裝Helper變得很棘手，如何把需要的對象依賴注入到Helper靜態方法中呢？?
你如果直接import引入Angular API，這樣封裝出來的Helper行為上可能是錯的，比如HttpClient的攔截機制，import創建的HttpClient實例脫離了Ioc框架，這將導致攔截失效。?
一種辦法是避開靜態方法，你可以注入Util類，這樣就可以拿到Angular Ioc容器中的相關實例了，這確實是個辦法。?
不過你如果希望使用靜態方法，有沒有辦法現實呢？?
服務定位器( Service Locator )
依賴注入威名遠播，以至于很多人并不清楚它還有個同父異母的弟弟 —— 服務定位器。
服務定位器是Ioc的另一種使用模式，你可以在代碼中主動調用Ioc容器方法“拉取”依賴對象，這會導致你的代碼與Ioc框架耦合，讓代碼也更難測試。
服務定位器儼然成為一種反模式，那么它是否已經一無是處了呢？
我發現在大多數情況下，并不需要服務定位器，但在某些情況下，它卻非常有用。
哪種情況需要服務定位器？當你無法使用依賴注入時，就該它出手了。
比如靜態方法，你就無法使用依賴注入，通過服務定位器方式仍然可以訪問Ioc，這對于封裝框架Helper有非常重大的意義，我會在本系列后續文章介紹服務定位器在.Net Core服務端封裝上的應用。?
Util Angular Helper大量使用了服務定位器，以更簡單的方式提供常用API。?
Util Angular Helper介紹
Helper
它位于/Typings/util/common/helper.ts，包含一些常用操作，比如空值判斷，類型轉換等，helper.ts內部將操作委托給lodash等第三方js庫。
IocHelper
?
它位于/Typings/util/angular/ioc-helper.ts。
IocHelper內部保存了Angular Ioc容器實例，以方便其它Helper以服務定位器的方式來訪問Ioc容器。
由于Angular Ioc具有分級特性，所以保存了模塊級和組件級兩種容器，對于獲取路由參數等操作，必須從組件容器獲取實例，否則將導致錯誤的行為。
在什么位置設置Angular Ioc容器呢？
模塊級容器在AppModule根模塊中設置，組件級容器需要在每個組件設置，這造成了不便，尚未找到更優雅的方式。
?
下面演示了IocHelper的用法。
let client = util.ioc.get<HttpClient>(HttpClient);HttpHelper
對于業務操作，使用得最頻繁的Angular Api莫過于發送Http請求，從服務端獲取Json數據,或將表單數據傳遞給服務端處理。
Util通過HttpHelper，WebApi，Form三個Helper從不同層次對Http操作進行了封裝。
HttpHelper位于/Typings/util/angular/http-helper.ts，對Angular?HttpClient進行了簡單包裝，提供原始Http操作。
Util盡量提供同步Api，使用回調函數，而不是Rx的Observable或異步Promise，這樣團隊成員只要具備JQuery經驗就能開發，降低了團隊的學習成本。?
在絕大多數情況下，你并不需要調用HttpHelper，WebApi和Form操作類會提供更多默認行為。
WebApi?
在發送Http請求時，你通常需要處理異常。?
異常可分為Http異常和業務異常兩類。?
Http異常是未成功的Http響應，比如Http狀態碼為500的服務器內部錯誤。Http異常通常和業務無關，所以每次發送請求設置Http異常處理是枯燥乏味的。?
另一方面，Http返回200成功信號并不代表業務執行成功，所以不應該通過Http狀態碼來識別業務是否成功完成。?
通過客戶端和服務端約定標準通信格式可以簡化異常處理。?
先來看客戶端結果類型。
?
?
下面是服務端結果類型。
?
?
WebApi操作類位于/Typings/util/common/webapi.ts，它在HttpHelper的基礎上，設置了默認的Http異常處理，將Http異常輸出到瀏覽器控制臺，以方便排錯，另外將服務端返回結果轉換為客戶端標準結果類型。?
下面展示了WebApi操作類的用法，handler方法是成功處理函數，你不用進行任何狀態判斷，WebApi內部已經處理過了。注意result參數并不是我們定義的標準Result類型，而是Result的data屬性，也就是實際業務類型，前后端標準通信格式被封裝起來。
Form?
對于管理后臺，大多為表單操作，所以我們對表單需要特殊關照。?
Form操作類位于/Typings/util/common/form.ts，它內置了一些表單常見操作。?
當表單提交失敗，通常會提示一個錯誤消息，以指示用戶修正錯誤。
?
錯誤提示是Form操作類的默認設置，你也可以取消它。
?
有時候，你希望在提交表單前先確認一下。
?
?
通過設置一個屬性就完成任務是不是很爽？?
?
Form操作類還包含很多有用的功能，下面是它的參數定義。
?Form操作類參數
Form操作類建立在WebApi操作類之上，而WebApi操作類建立上HttpHelper之上，通過層層包裝，讓Http請求變得更加簡單易用。
RouterHelper?
Angular提供了路由機制，路由訪問是僅次于Http請求的操作。
通常需要從路由中獲取參數。
RouterHelper用于操作路由,位于/Typings/util/angular/router-helper.ts，在內部使用服務定位器訪問ActivatedRoute，簡化了路由訪問。
Message?
表單操作經常需要彈出各類消息框，比如成功提示框，錯誤提示框，確認提示框等。
Message操作類集成封裝了PrimeNg和Angular?Material的消息框，它位于/Typings/util/common/message.ts。
?
下面彈出了一個錯誤消息框。
util.message.error("哈哈");Dialog
Dialog操作類封裝了Material彈出層，位于/Typings/util/common/dialog.ts。
?
?
下面演示了將外部網頁加載到iframe中。
?
加載業務組件應使用dialogComponent屬性。
?
Util Angular CRUD基類介紹?
Js是一種弱類型語言，通過原型鏈和閉包可以模擬出面向對象的特征，雖然看過一些文章說Js其實比C#這樣的面向對象語言更加OO，不過我始終沒有感覺出來，這或許是專業水平和我這種半吊子水平的區別所在吧。
前幾年我對Js的封裝僅限于Helper或組件，服務端摸索出來的經驗很難應用到Js，雖然能模擬出我想達到的效果，但卻不是那么直觀。
雖然有人常說語言不是問題，語法更不是問題，但那指的是高手，在尚未達到高手境界以前，我們需要更優雅的語法糖，這使你寫起來心情舒暢，開發業務效率倍增。
Typescript提供了強大的語法糖，包括面向對象基本語法，泛型，lambda表達式等，Angular則提供了Ioc等服務端才具備的特性，這對于具備服務端架構設計經驗的朋友，無疑是把利器。
對于簡單Crud操作，來回就那幾句重復代碼，能否在Angular開發中像C#一樣封裝個基類呢？
有了Typescript和Angular，這是非常輕松的任務。
TableQueryComponentBase?
對于簡單Crud，通常在主界面放一個表格，并提供Crud操作。
TableQueryComponentBase是表格查詢基類，它提供了從表格刪除行，刷新表格，搜索等功能，位于/Typings/util/base/table-query-component-base.ts。
有了基類，業務組件將變得十分干凈。
?
Angular官方推薦將業務操作從組件分離，使用服務的形式依賴注入到組件，這讓你的設計更加內聚。
不過我沒有機械的執行這一指南，僅在業務操作變得復雜時使用這種方式，在更多的簡單場景，我會把數據操作直接內置到組件中。
EditComponentBase
EditComponentBase是Crud編輯基類，除了提交表單以外，它還能從路由取得Id并從服務端加載數據，位于/Typings/util/base/edit-component-base.ts。
?
?
ApplicationEditComponent示例類重寫了loadById和submit方法，刪除掉同樣可以工作，當你有特殊要求的時候進行重寫。
FormComponentBase?
一個常見的需求，當表單已經被更改時，跳轉頁面需要提示用戶保存。
FormComponentBase是表單基類，位于/Typings/util/base/form-component-base.ts，它提供了表單變更值檢查方法。
?
TreeTableQueryComponentBase?與?TreeEditComponentBase
與TableQueryComponentBase和EditComponentBase類似，這兩兄弟也是用來支持簡單Crud操作的，不過它們用來支持樹型關系。
繼承基類，收工，不要在簡單Crud上浪費過多時間。
?
?
Util Demo的role示例演示了樹型Crud的用法。
小結
本文簡單介紹了Util Angular Helper的封裝，使用服務定位器封裝成鏈式，所有helper都內聚在util這個命名空間下，這大幅提升了Angular的易用性，對于常用功能，不用記憶任何API，憑借一點模糊的印象就能夠完成任務。
另外介紹了為簡化Crud提供的基類，這和服務端Crud封裝很相似，得益于Typescript和Angular所提供的強大語法糖。
未完待續，Angular 組件封裝及TagHelper將在下篇介紹。
寫文需要動力，請大家多多支持，點下推薦，Github點下星星。
Util應用框架交流一群: 24791014
Util應用框架地址：https://github.com/dotnetcore/util
相關文章：
.Net Core應用框架Util介紹（一）
.Net Core應用框架Util介紹（二）
.Net Core應用框架Util介紹（三）
原文地址:?https://www.cnblogs.com/xiadao521/p/Util-Introduction-4.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的.Net Core应用框架Util介绍（四）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 中国开源年会 COSCon 2018 今
- 下一篇： 使用 dotTrace 分析 .NET