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