.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中使用依赖注入，有没有什么缺陷呢？下面来看个例子。

/**
* 表单提交参数
*/
export interface IFormSubmitOption {
/**
* 服务端地址
*/
url: string;
/**
* 数据
*/
data;
/**
* Http头
*/
header?: { name: string, value }[];
/**
* Http方法
*/
httpMethod?: HttpMethod;
/**
* 确认消息,设置该项则提交前需要确认
*/
confirm?: string;
/**
* 确认标题
*/
confirmTitle?: string;
/**
* 表单
*/
form?: NgForm;
/**
* 按钮实例，在请求期间禁用该按钮
*/
button?,
/**
* 请求时显示进度条，默认为false
*/
loading?: boolean,
/**
* 提交失败是否显示错误提示，默认为true
*/
showErrorMessage?: boolean;
/**
* 提交成功后是否显示成功提示，默认为true
*/
showMessage?: boolean;
/**
* 提交成功后显示的提示消息，默认为"操作成功"
*/
message?: string;
/**
* 提交成功后是否返回上一个视图，默认为false
*/
back?: boolean;
/**
* 提交成功后关闭弹出层，当在弹出层中编辑时使用，默认为false
*/
closeDialog?: boolean;
/**
* 提交前处理函数，返回false则取消提交
* @param data 数据
*/
beforeHandler?: (data) => boolean;
/**
* 提交成功处理函数
* @param result 结果
*/
handler?: (result) => void;
/**
* 提交失败处理函数
*/
failHandler?: (result: FailResult) => void;
/**
* 操作完成处理函数，注意：该函数在任意情况下都会执行
*/
completeHandler?: () => void;
}

Form操作类参数 [p]　　Form操作类建立在WebApi操作类之上，而WebApi操作类建立上HttpHelper之上，通过层层包装，让Http请求变得更加简单易用。

• RouterHelper 

　　Angular提供了路由机制，路由访问是仅次于Http请求的操作。

　　通常需要从路由中获取参数。

[/p]

　　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