正如我在<
如何用ABP框架快速完成项目(2) - 快的定义!>提到的, 很多同学在使用ABP中遇到很多问题, 花了很多时间和精力, 然而从最根本的角度和方向上来看这些问题应该是不存在。
这些问题如果你正确使用了ABP是根本不会遇到这些问题的.
那么如何正确使用ABP呢?
首先我们要与时俱进，既然选择了ABP，其他同时代的技术和思想也要一并选择.
举个例子, 我们既然选择了飞机, 就要把导弹也选上, 不要开着飞机然后用弓箭去和敌人开战.
那么同时代和ABP这架飞机匹配的武器有啥呢?
- .NET core和Angular/Vue等SPA框架
- 微服务
- BDD/TDD
- DevOps
其中DDD因为和ABP本身绑在一起, 所以就不单列了.
我们先从第一个说起, .net core和Angular/Vue等SPA框架
- ASP.NET MVC 5.x + MPA
- ASP.NET MVC 5.x + AngularJS
- ASP.NET Core 2.x + MPA
- ASP.NET Core 2.x + Angular/Vue.js
为什么我不再使用
ASP.NET MVC 5.x版本? 因为:
- ABP vNext已经明确不支持.NET, 不支持Asp.NET MVC 5.x, Entity Framework 6
- 微软也不再更新ASP.NET MVC 5.x, 全部重心都放在ASP.NET Core
- Google自己都抛弃了AngularJS
那么为啥不使用
ASP.NET Core 2.x + MPA呢? 因为:
- 我本人从来没有编译通过过.NET Core + MPA版本, 看来ABP对这个版本支持力度很小.
- 时代趋势是前后端分离, 流行SPA, SPA不但可以在网页端跑还能在PC端(Electorn)和移动端(Ionic)上跑.
注: 之前有同学使用
ASP.NET MVC 5.x + MPA入门, 花了一个上午都没有跑起来, 原因就是和我从来没有编译通过过.NET Core + MPA版本一样, ABP对这个版本支持力度很小了. 甚至没编译通过都敢Release.
微服务和BDD\TDD还有DevOps会在后面章节详细讲, 所以这里就跳过了.
然后现在是2018年了, 就不要用1998年的软件开发思维啦. 所以:
- 不要升级项目。不要在旧项目上用abp
- 通过微服务分隔项目，在小的新项目上用abp
1998年的时候, 我们开发软件很期待dll新版本，一有dll新版本就升级.
因为那时候车马很慢，书信很远，
一生只够爱一个人, windows/office两三年才发布一个新版本, 以年为单位
现在基本所有技术都6个月发布一个新版本, 以月为单位, 比如我所用的技术:
- 去年今日, 用的是Activiti 5, 现在用7, 一年出两个版本
- 去年今日, 用的是Angular 4, 现在用7, 一年出三个版本
更新如此之快, 导致向前兼容性变得很差, 比如:
- Angular 1和Angular 2区别巨大，完全是不同两个框架。
- Angular 6的Rxjs不兼容Angular5
- Angular 7的表单丢弃部分旧版本支持
- ABP 3.8 UserManager类去掉CreateIdentityAsync()导致大量代码要重写
- ABP经常会有Breaking Changes: https://github.com/aspnetboilerplate/module-zero-forsaken/releases
也就是说, 2018年和1998年不一样啦, 每次升级都有可能导致程序跑不通了, 要改代码甚至要重写大量代码.
这也是Nuget和NPM存在意义之一.
所以不要升级项目, 不要在旧项目上用abp, 因为不但可能要重写大量代码, 甚至因为对abp不熟, 连应该怎样重写都不会.
然后通过微服务分隔项目, 在小的新项目上用abp, 从而避免新旧版本不兼容的灾难.
本节文章可能会吓到不少同学, 然而整个行业都是如此, 只要你还在编程届, 想拿高薪, 你必须面对这个事实. F117都退役了, 现在换F35了, 新时代的武器有新时代的玩法.
所以有同学问ABP团队现在正在开发新的ABP, ABP vNext, 你怎么看? 我觉得正常! 我们只能适应它.不过ABP vNext还没正式发布, 就算正式发布也得需要一段时间去填坑, 所以不推荐用在正式项目中.
一句话做为本节文章的结尾吧: 快马配弓箭, 飞机配导弹, 不要开着飞机却拿着弓箭去和敌人开战.