从ABP框架国内社区发展回顾.NET技术变迁-2017

我的技术回顾那些与ABP框架有关的故事-2017年

从2022年来回顾ABP框架，我们会发现无论是商业模式还是架构设计思路，如果没有良好的商业模式的话，ABP框架很容易进入难产的状态，比如之前很多的Blazor Blog 模块，因为没有商业支持，导致已经临近2年没有维护了。

所以我们在选择框架的时候，既然重视它的架构设计，技术选型也要选择能够有实力做到可以持续更新的框架。

面临变革的ABP框架

2017年的ABP，对于ABP框架的作者来说无疑是一个充满了挑战的一年。

.NET Core 虽然出来了，但是很多公司用于它做做小项目，或者尝鲜还行，直接贸然的更换为主力开发框架这个对于每个公司来说都是充满了战略级的决定。

对.NET 开发者来说充满了挑战的一年，由于技术惯性，大部分的开发人员都是在.NET Framework中工作，采用的服务器都是Windows，对于.NET Core的新特性掌握的并不扎实。对于其他的技术方案如容器化，Nginx并不感冒。

但技术和市场，以及客户环境是不会容忍你的停滞，因为这一年整个技术圈都在发生变化，大家开始提倡微服务、中台、工业4.0、大数据、云计算这些新的技术概念，这些概念在目前来说 落地到了云原生的场景。

那么.NET 如果要跟上这样的流行趋势，那么势必也要变化和调整。对于ABP来说，也是一样的。它需要照顾好以前的老客户群体，即：.NET Framework的用户群，同时又要兼容.NET Core 的发展趋势。

这个对于任何一个架构师来说都是非常难的。所以ABP框架在2017年开始疯狂的补充文档和适配.NET Core，中途可以看到随着ABP框架作者对于.NET Core的了解越深。里面开始增加了很多只有.NET Core才有的特性,17年ABP框架发布了几个比较大的版本，尤其是v2.0。

ABP框架v2.1发布(2017年6月)

不提2.0的原因是，2.0的版本一直在快速的迭代和发布，中间从2.0升级到2.1变更了太多的东西。当然大部分的开发者还停留在1.0，如果不是为了特意的技术研究也不会去翻阅2.0的源码和内容。

所以2.1的版本在我看来是最固定的版本内容。

大家比较可能比较熟悉的是支持Dapper模块，当然还有其他很多功能和内容。

但其实在内部也做了非常灵活的封装方法，即CrudAppService 。便于快速的完成CRUD操作，达到快速开发的目的。

• 本地化、多语言、增强工作单元这些基础设施内容

.NET Core 2.0 发布(2017年8月)

2017年8月.NET Core 2.0发布后，ABP框架升级到.NET Core 2。作者紧随其后发布ABP v3.0.0的版本，这版本也基本奠定了后面会将abp剥离一个单独仅支持.NET Core的解决方案。这个也会更加的偏重于微服务、模块化的方向，更侧重于向DDD靠拢，抛弃掉为了兼容.NET Framework 要做的妥协。

前端方案的选择与变化:vue还是angular

2017年前端开发框架也开始了从angularjs1.x升级到angular2的变化。国内开发者喜欢vue1.x升级vue2的解决方案。

彼时去哪儿还没有被携程合并，司徒正美的阿瓦隆(avalon.js)也是这个时候的主流。但是因为运营和生态的问题，慢慢被挤出市场。

如果你关注前端技术圈，会知晓司徒正美大佬，因为脊椎病于2020年3月逝世。

更多详情请参考：回忆与前端大神司徒正美(钟钦成)的二三事与大龄程序员猝死问题

不过关于司徒正美，其实也是一个简单的故事，一位来自农村的少年，不在乎命运对他的捉弄，勇敢经历短暂的人生，在二次元继续寻找着技术的真谛。 by 刘悦

17年的时候整个市场上angular2和vue2以及react都在属于三雄争霸的时代，大家分别从各自的维度上来蚕食着JQuery的份额。

从国内来看vue2靠着它的入门门槛低，人员薪资便宜，国内特殊的小程序生态圈，占领了国内的整个前端的生态圈。国外的话angular、react、vue依然是三足鼎立的态势。

所以很多时候，运营好了之后，会给技术如虎添翼。

ABP框架在前端的默认支持方案-Angular4

Angular因为依托于TypeScript的强类型语言特性，ABP自然会选择生态和设计偏重于后端的解决方案：Angular。

当然这个不是最重要的，在我看来，最重要的是ABP的商业版本是要打造一个包含前后端的解决方案，而在这种时候，大多数是可以靠功能进行控制的。

在React框架里面我记得有一句话叫做：单向数据流，后来在Vue里面这句话也当做一个标准，后来被调整为双向数据流，但是组件之间的管理又推崇单向数据流。（扯远了）

但是从单向数据流这个标准来说，最后所有的东西是从数据库、经过后端的逻辑配置为功能后，前端进行渲染和输出是最合理的。这样前端的人员可以花更多的心力在交互体验上了。

所以很多时候ABP框架为了可控，尤其在针对复杂项目的时候，你会发现它会相当的节约人手，因为大部分的活都在后端以及框架层面解决了。当然也会带来的问题就是后端开发起来比较繁琐。所以需要有代码生成器。

传统的JQuery并未被抛弃

当然MVC方案下的jquery+datatable.js的形式依然保留，在这个方案下依托于abp.js为主的DOM JavaScript方案，依然会让选择用传统形式开发的小伙伴觉得非常香。尤其采用了统一封装的代码写法了之后，开发体验程度也会高上很多。

而能把这些方案做的如此完善的原因，是因为ABP框架的作者是一个真正的全栈工程师和产品经理。因为他还有一个前端表格插件jtable.org。

所以像ABP作者这样，深耕于技术领域，从后端、前端如此精通的人，加上对于业务的理解，这样的大牛所做出来的框架，我实在找不到第二个选择了。

正式开始ABP框架的对外推广

2017年对于我来说变化尤为重要，在公司内部从开发者变成技术经理到项目经理，对一年跨了3个岗位。

而随着群员越来越多，人员水平并不均衡，也不是所有人都有能力去直接看ABP框架的源码。

我也受邀如鹏网杨中科老师，作为校友开始了第一次对外直播分析ABP框架。

分享完成后了之后，加群的人也变多了。然后我开始录制一个简单的电话薄的Demo给大家。

放在了倒闭了的百度传课平台上，你看又一个经营不善的平台。所以看不到了，而且过于早期说实话我自己都瞧不上。

分享带来的额外收获-微软MVP

随着基础性的文章分享越多，无论是博客也好、视频也罢。同时公司内部项目增多，人手紧缺，我也被拉着往管理岗上走，说实话，也在积微的那几年见到了太多，这个对于大部分人来说都是不可复制的经历。

昙花一现的DNC社区

2017的时候，新东方的mike成立了昙花一现的DNC社区，上图为dnc社区峰会截图。后来因为新东方加班996太严重，导致后继乏力。

但是也非常感谢Mike，在他建立的社区群里，我认识了很多非ABP框架圈子的技术大牛。当然在这个DNC社区里，有太多的大牛，所以也闹出了一些不太愉快的事情，不过现在想来，那个时候我还只是一个吃瓜群众，还算好。

然后结识了成都.NET MVP老大哥，朱永光大哥。然后他带着我们一起做.NET 有关的技术活动、然后陆续和CAP框架杨晓东、晓晨认识，慢慢接触到了NCC社区。

聊聊NCC社区

现在的我已经不是一个纯粹的程序员了，但是你如果想深耕技术，我想NCC社区是一个非常推荐你去了解的社区和组织，虽然我从来没有和NCC社区的人有过正式合作。但是非常欢迎你去了解他们，是一个真正中立致力于.NET 技术推广的社区。

所以.NET的社区有很多，但是因为大家都经营的很佛系，所以不太知道罢了。

而在2017年成为MVP之后，参加了太多的技术活动，开阔了无数的眼界，现在想来，2017年微软的很多客户落地的一些项目方案，到2021年了才开始有国内的公司出现在了解和使用。

最初分享技术的时候并没有想过要成为微软MVP，但是因为成为了微软MVP让我在推广技术的时候可以得到很多额外的助力，比如

• 成为微软MVP，我可以获得很多的技术支持。
• 可以直接和微软dotnet团队对话，看到非常多的内部资料。
• 可以直接参加微软的技术活动。
• 可以享受到微软以及它生态联盟里面多大200多种产品的免费使用。
• 微软内部大量的免费学习资料（前提英语要好），可以看到很多解决方案。
• 19年后还赠送了每年Azure 1w美刀的额度给我们。
• 等等内部的权益，包括对于你的职业生涯也有很大的助力。

所以踏实做事，总会得到很多额外的惊喜。

如果有机会，我或许会再写一篇《我的微软MVP五周年》记录吧！