這節文章十分重要!十分重要!十分重要!
很多同學在使用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項目去調用.