网站开发销售,网站做好后交接,做网站资讯,公众号怎么编辑制作距离上次发文#xff0c;已经过去了三年半#xff0c;这几年技术更新节奏异常迅猛#xff0c;.Net进入了跨平台时代#xff0c;前端也被革命性的颠覆。回顾2015年#xff0c;正当我还沉迷于JQuery EasyUi的封装时#xff0c;突然意识到技术已经过时。JQuery在面对更加复… 距离上次发文已经过去了三年半这几年技术更新节奏异常迅猛.Net进入了跨平台时代前端也被革命性的颠覆。回顾 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框架AspectCoreSavorboard杨晓东的分布式事务解决方案CAP框架以及我的应用框架Util。随后一些优秀的开源项目加入了NCC包括爬虫解决方案DotnetSpider分布式微服务框架Surging等。Util产生的背景 我长期混迹于小型软件公司小公司资源有限人少事多水平也参差不齐如何降低团队的学习成本如何提高项目的开发进度如何降低Bug率是我的主要关注点。 Util应用框架是我在多年的项目实战中积累起来以解决上述问题的利器实践证明它在多个小型团队和多个中小项目上起到关键作用甚至包括一些濒临流产的项目。中小项目的瓶颈在哪 对于中小项目简单CRUD增删改查占据大量篇幅核心模块包含复杂业务逻辑报表包含复杂查询另外还需要权限控制、流程控制等不管模块再多大体不出这个范围。 前端UI体验变得越来越重要工作量也越来越大。一个简单CRUD服务端API开发半小时UI可能需要折腾一天。如何打破瓶颈 如果能够迅速拿下CRUD并且能有效减轻前端开发任务那么就能将更多精力投入核心业务从而提高项目交付能力。 对于服务端CRUD通过封装基类再配合代码生成就能很好解决如何提升前端开发效率正确认识前后分离 一些人鼓吹“前后分离“原则前端界面交给专业的前端人员后端人员只负责提供API就好了这似乎是提升前端开发效率的灵丹妙药。 问题在于小公司资金预算有限而专业前端人员薪资要求很高以低价招聘的前端人员往往只会HTML CSSJS耍得并不溜最后还得服务端程序员上场。 另一方面前端还有前台和后台之分前台是面向终端用户的网站比如门户网站商城一类前台偏重展示规律性不强后台是面向用户或管理员的表单系统偏重功能规律性比较强。大多公司的前端人员主要开发前台网站而管理后台还是服务端程序员开发前端人员顶多帮助界面布局功能还是后端人员完成。 前后分离不一定是人员的分离也不能降低工作量主要是指前后端依赖关系的分离如果前端技术或后端技术可随意替换而不是绑定在一起就认为分离成功这提升了项目的可维护性。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就完成了验证工作这相当酷。 1input required”true” 不过我发现很多团队并不使用声明式编程方式更愿意使用Js原因在于Html是弱类型标签自定义属性并没有代码提示这确实是个大问题。TagHelper - 编写Html的救命稻草 我在2012年学习Dwz这个前端框架时接触到声明式编程的概念也被Html无提示的问题所困扰后面发现Asp.Net提供的HtmlHelper能够封装Html提供强类型的代码提示这正是我需要的特性。 2015年用HtmlHelper封装了EasyUi虽然只完成了一些基础工作但使用过的人都认为它大量提升了开发效率它现在甚至仍然是一些公司的主打技术。 HtmlHelper也有缺陷它看上去是C#代码而不是标签比如HtmlHelper封装的文本框长成这样。 如果需要前端同学来帮助你调整界面这就不太友好了。 另外HtmlHelper与Html混在一起也让代码看上去不直观。 微软发现了这个问题在Asp.Net Core推出了TagHelperTagHelper与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点下星星。 Util应用框架交流一群: 24791014原文链接https://www.cnblogs.com/xiadao521/p/Util-Introduction-1.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
