这节文章十分重要!十分重要!十分重要!
很多同学在使用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项目去调用.