如何用ABP框架快速完成项目(7) - 用ABP一个人快速完成项目(3) - 通过微服务模式而不是盖楼式来避免难度升级和奥卡姆剃刀原理...

这节文章十分重要!十分重要!十分重要!

 

很多同学在使用ABP的过程中遇到很多问题, 花费了很多时间和精力都还无法解决, 就是卡在这节文章这里.

 

Talk is cheap, just show your code! 让我们上实例.

 

以很多人都会遇到的导入excel功能为例吧. 因为 LinqToExcel是那么的优秀, 我们选择使用它来操作Excel数据.

很多同学直接在ABP项目里面用nuget安装 LinqToExcel, 然后使用, 这就是盖楼式. 在ABP这层楼上再盖上 LinqToExcel这层楼.

好啦, 问题出现, 很快就发现会报错. 而 LinqToExcel 作者明确表示这个锅他不背.

同时单独新开一个VS默认的Project然后使用 LinqToExcel并没有报这个错误.

看来的确不是LinqToExcel的锅, 那这个锅只能由ABP来背了.

 

于是很多同学就开始找文档啊, 看ABP源代码啊, 搜资料啊, 花了很多时间, 并没能把问题解决.

 

我们这系列文章的关键词就是”快速”! 就算能把问题解决,如果要花很多时间, 那也不能算成功.

 

我们的解决方法超级简单, 采用微服务的方式, 直接在52ABP solution里面新加一个VS默认的Project, 引用LinqToExcel去处理Excel, 并以web方式发布, 然后在abp项目中调用这个web服务即可! 实际用时半小时到一个小时! 问题解决! 还超快速!

 

等等, 说好的微服务, 为啥我们没有看到k8s的踪影? 这就是我们要说的 奥卡姆剃刀原理啦: 如无必要, 勿增实体.

 

在这里我们使用LinqToExcel只是用来导入Excel, 这个功能不会经常用上, 故障容忍度比较高. 而加入k8s来管理则是要花时间和精力成本的, 这不符合”快速”这个原则.

 

当然如果这块功能在业务上很重要, 值得花时间和精力上k8s, 那么该上的还是要上的.

 

另外一个常遇到的场景就是, 有些优秀的.NET库暂时不支持.NET Core, 所以无法在ABP里面直接使用. 如果采用盖楼式改写这些库的代码来支持.NET Core, 那是严重违背了”快速”这个原则, 所以我们也和上面LinqToExcel的例子, 采用微服务的方式, new一个web project来让ABP项目去调用. 

转载于:https://www.cnblogs.com/adalovelacer/p/abp-quickly-delivery-7-one-person-project-3-use-micro-service.html