在线教育平台网站建设,提供手机网站开发,wordpress国外主题网站模板,文化建设网站上篇介绍了Util Angular Demo的目录结构和运行机制#xff0c;本文介绍Util封装Angular的基本手法及背后的动机。Angular应用由Ts和Html两部分构成#xff0c;本文介绍第一部分。Angular Ts的封装Ts是Angular的代码部分#xff0c;用于编写页面逻辑。依赖注入( Dependency I… 上篇介绍了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.getHttpClient(HttpClient);HttpHelper 对于业务操作使用得最频繁的Angular Api莫过于发送Http请求从服务端获取Json数据,或将表单数据传递给服务端处理。 Util通过HttpHelperWebApiForm三个Helper从不同层次对Http操作进行了封装。 HttpHelper位于/Typings/util/angular/http-helper.ts对Angular HttpClient进行了简单包装提供原始Http操作。 Util尽量提供同步Api使用回调函数而不是Rx的Observable或异步Promise这样团队成员只要具备JQuery经验就能开发降低了团队的学习成本。 在绝大多数情况下你并不需要调用HttpHelperWebApi和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
