.NETCore 千星項目模塊化開發框架 SimplCommerce 詳解

SimplCommerce 是 github 上過千星的.netcore 商城示例項目，本文詳解他的模塊化框架現實思路，其業務（如產品、訂單）不做介紹。因做者文筆水平不好，它又很值得學習和推薦，就算不要臉獻醜一次吧，如對本文有不明白之處望見諒留言，謝謝。

 

早期單體開發框架，由於簡單上手快的特色廣受青睞。可是隨着項目時間的考驗，最終變得難以維護，臃腫、規範、污染等劣勢致使人力成本增長。文章後方有 ABP、微服務、模塊化、單體應用場景分析。

 

SimplCommerce 特色

 

分解

一個超級大的項目，主程能夠按功能拆分紅N個平行的小模塊，每位開發成員都清楚本身負責的模塊。

如上圖： Modules 目錄裏的子項目都是分解後的模塊

獨立

新人是項目開發中最具破壞力的元兇之一，模塊間獨立、隔離能夠有效的限制他們，避免核心模塊或總體污染。

每一個模塊能夠有本身的數據庫、配置(appsettings.json)、Controller、Views(razor模板)、wwwroot(靜態資源)

可擴展性

策劃說要增長代理功能，新增一個模塊來開發，既不影響原有模塊，對開發人員等同是新的小項目，從而更簡單。

這個雪球能夠一直滾下去，哪怕增長100個新模塊，給兵就能打勝仗。

可維護性

得益於分解、獨立特性，每一個模塊代碼更少，交接成本、調試成本更低。

舉一個極端的例子，需求改不動了怎麼辦，重構此模塊也不過如此吧，沒必要牽一髮而動全身。

可組合性

模塊可單獨、或者組合部署。

好比獨立部署：Modules/SimplCommerce.Module.Orders 因爲訪問量較大獨立到 A 服務器

好比組合部署：Modules/SimplCommerce.Module.Catalog、Modules/SimplCommerce.Module.Cms 因爲沒有壓力獨立到 B 服務器

 

SimplCommerce 模塊化框架現實分析

如上圖，這是 Catalog 模塊的目錄結構，看上去和普通和 mvc 沒什麼區別，仔細看他還少了點什麼，對。。。沒有 Program.cs、Startup.cs

 

問：他怎麼啓動運行呢？

答：模塊只負責現實功能，SimplCommerce.WebHost 纔是啓動項目。

 

問：SimplCommerce.WebHost 啓動怎麼加載 Catalog 裏的 mvc 代碼？

答：請看 SimplCommerce.WebHost/SimplCommerce.WebHost.csproj

<Target Name="CopyModules" AfterTargets="Build">
    <Exec WorkingDirectory="." Command="npm run gulp-copy-modules -- --configurationName $(ConfigurationName)" />
  </Target>

編譯成功後執行 npm run gulp-copy-modules（源碼在 SimplCommerce.WebHost/gulpfile.js)，採用 node + gulp 將 Modules 全部模塊編譯結果與所需資源複製到 WebHost 目錄之下。

編譯成功後的僞動做大體以下：

複製 SimplCommerce.Module.Catalog/bin/Catalog.dll 到 SimplCommerce.WebHost/Modules/Catalog/Catalog.dll

複製 SimplCommerce.Module.Catalog/Views/* 到 SimplCommerce.WebHost/Modules/Catalog/Views/

複製 SimplCommerce.Module.Catalog/appsettings.json 到 SimplCommerce.WebHost/Modules/Catalog/appsettings.json

複製 SimplCommerce.Module.Catalog/wwwroot/* 到 SimplCommerce.WebHost/wwwroot/

dotnet 運行 SimplCommerce.WebHost 時作了如下現實：

一、反射加載 Modules/Catalog/Catalog.dll、Modules/Catalog/Views，因爲現實代碼過多，本文不貼出（現實源碼在此：SimplCommerce.WebHost/Extensions/ServiceCollectionExtensions.cs）

二、合併 appsettings.json 配置文件，採起了相似如下的代碼

var confg = new ConfigurationBuilder()
  .SetBasePath(env.ContentRootPath)
  .AddJsonFile("appsettings.json", true, true)
  .AddJsonFile("Modules/Catalog/appsettings.json", true, true);

三、wwwroot 已天然合併。。

 

問：SimplCommerce.WebHost 須要常常維護嗎？

答：不須要，它實現了動態加載模塊，項目開發人員只須要負責較簡單的 Module。

 

問：若是模塊定義太多，如何所有編譯？

答：因爲 vs 太方便，右擊 Modules 目錄就能夠所有編譯了。

 

源碼地址：https://github.com/simplcommerce/SimplCommerce

特別介紹，因爲做者太菜2016年轉型 .net core 項目時，它就已通過了千星，星多表明着生態，且用且珍惜。

 

各大開發框架應用場景分析

ABP

基於 DDD 開發的實踐項目，.NETCore 2.0發佈之後，國內不少我的用它學習上手，也有公司開始使用它開發項目。

絕對是大團隊才傷得起的選擇，學習和使用成本較高，做者編程13年玩不轉它，您要說我菜，我認。

它的缺點不少我就不說了，由於ABP粉絲太多怕被噴死。。至少他不適合我。

微服務

很少做介紹，這個詞是個程序員都聽過了解過，有不少實踐項目如eShopOnContainers，有人說玩轉他就通了一切。

我是這樣理解微服務應用場景的：

一、只有當服務器壓力很大的狀況下，才考慮拆拆分微服務。

二、只有需求變更較小、訪問量超大的狀況下，才考慮微服務架構，好比電商。

它須要很強的架構師。

它不適合小團隊。

它不適合作需求氾濫的項目。

它不適合功能型太複雜的項目。

模塊化

本文介紹的便是模塊化開發框架，天生適合中大型項目開發，而且爲之後拆分紅微服務架構奠基了基礎。

單體

適合我的或小型項目，優勢：快。

 

總結

每種技術框架存在便是合理的，各有優勢和缺點，沒有哪一個最好哪一個最壞，在合適的場景選擇合適的框架，它就是把雙刃劍，反之將貽誤終生。

 

花了半天時間寫這篇文章，但願點讚的兄弟下個月能加工資500，謝謝觀看。