上篇介绍了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操作类还包含很多有用的功能，下面是它的参数定义。
1 /** 2 * 表单提交参数 3 */ 4 export interface IFormSubmitOption { 5 /** 6 * 服务端地址 7 */ 8 url: string; 9 /** 10 * 数据 11 */ 12 data; 13 /** 14 * Http头 15 */ 16 header?: { name: string, value }[]; 17 /** 18 * Http方法 19 */ 20 httpMethod?: HttpMethod; 21 /** 22 * 确认消息,设置该项则提交前需要确认 23 */ 24 confirm?: string; 25 /** 26 * 确认标题 27 */ 28 confirmTitle?: string; 29 /** 30 * 表单 31 */ 32 form?: NgForm; 33 /** 34 * 按钮实例，在请求期间禁用该按钮 35 */ 36 button?, 37 /** 38 * 请求时显示进度条，默认为false 39 */ 40 loading?: boolean, 41 /** 42 * 提交失败是否显示错误提示，默认为true 43 */ 44 showErrorMessage?: boolean; 45 /** 46 * 提交成功后是否显示成功提示，默认为true 47 */ 48 showMessage?: boolean; 49 /** 50 * 提交成功后显示的提示消息，默认为"操作成功" 51 */ 52 message?: string; 53 /** 54 * 提交成功后是否返回上一个视图，默认为false 55 */ 56 back?: boolean; 57 /** 58 * 提交成功后关闭弹出层，当在弹出层中编辑时使用，默认为false 59 */ 60 closeDialog?: boolean; 61 /** 62 * 提交前处理函数，返回false则取消提交 63 * @param data 数据 64 */ 65 beforeHandler?: (data) => boolean; 66 /** 67 * 提交成功处理函数 68 * @param result 结果 69 */ 70 handler?: (result) => void; 71 /** 72 * 提交失败处理函数 73 */ 74 failHandler?: (result: FailResult) => void; 75 /** 76 * 操作完成处理函数，注意：该函数在任意情况下都会执行 77 */ 78 completeHandler?: () => void; 79 }
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