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 时做了以下现实:
1, 反射加载 Modules/Catalog/Catalog.dll,Modules/Catalog/Views, 由于现实代码过多, 本文不贴出(现实源码在此: SimplCommerce.WebHost/Extensions/ServiceCollectionExtensions.cs)
2, 合并 appsettings.json 配置文件, 采取了类似以下的代码
- var confg = new ConfigurationBuilder()
- .SetBasePath(env.ContentRootPath)
- .AddJsonFile("appsettings.json", true, true)
- .AddJsonFile("Modules/Catalog/appsettings.json", true, true);
3,wwwroot 已自然合并..
问: SimplCommerce.WebHost 需要经常维护吗?
答: 不需要, 它实现了动态加载模块, 项目开发人员只需要负责较简单的 Module.
问: 如果模块定义太多, 如何全部编译?
答: 由于 vs 太方便, 右击 Modules 目录就可以全部编译了.
源码地址: https://github.com/simplcommerce/SimplCommerce
特别介绍, 由于作者太菜 2016 年转型 .net core 项目时, 它就已经过了千星, 星多代表着生态, 且用且珍惜.
各大开发框架应用场景分析
ABP
基于 DDD 开发的实践项目,.NETCore 2.0 发布以后, 国内很多个人用它学习上手, 也有公司开始使用它开发项目.
绝对是大团队才伤得起的选择, 学习和使用成本较高, 作者编程 13 年玩不转它, 您要说我菜, 我认.
它的缺点很多我就不说了, 因为 ABP 粉丝太多怕被喷死.. 至少他不适合我.
微服务
不多作介绍, 这个词是个程序员都听过了解过, 有很多实践项目如 eShopOnContainers, 有人说玩转他就通了一切.
我是这样理解微服务应用场景的:
1, 只有当服务器压力很大的情况下, 才考虑拆拆分微服务.
2, 只有需求变动较小, 访问量超大的情况下, 才考虑微服务架构, 比如电商.
它需要很强的架构师.
它不适合小团队.
它不适合做需求泛滥的项目.
它不适合功能型太复杂的项目.
模块化
本文介绍的即是模块化开发框架, 天生适合中大型项目开发, 并且为以后拆分成微服务架构奠定了基础.
单体
适合个人或小型项目, 优点: 快.
总结
每种技术框架存在即是合理的, 各有优点和缺点, 没有哪个最好哪个最坏, 在合适的场景选择合适的框架, 它就是把双刃剑, 反之将贻误终生.
花了半天时间写这篇文章, 希望点赞的兄弟下个月能加工资 500, 谢谢观看.
来源: https://www.cnblogs.com/kellynic/p/9347121.html