.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点下星星。