简单三层，力求精简。
.NET Core / .NET6 入门级项目。
可用于企业/公司基本项目（设计中考虑了分布式的情况，可多节点部署）。
关键词：通用后台管理系统、前后端分离、用户权限管理系统。
QQ交流群：694414280（欢迎广大 .NET 开发者加入）
个人2021年年初曾参考一个模块化的项目（SimplCommerce），试着从0到1搭建一个完整的项目，并应用在工作的项目里（当时就我一个开发，想搞啥搞啥，可太爽了）。今年再看那个项目，虽说结构、代码都很干净，但很多想法及实现还是太稚嫩了。而且模块化的架构，实际上只是更贴近我当时（上上家）的业务场景，不太适应通用的情况。
2022年7月新开的这个项目，期望实现这样的能力：业务人员只需关注实体的构建，业务服务的编写，以及路由的配置。
让业务的开发，变成简单的三步走：创建实体 >> 业务开发 >> 路由配置。
由于在学习其他方向，本项暂不升级 .NET7，待到 .NET8 发布再进行升级。
前后端分离，使用 JWT 认证。
后端：基于 .NET6 和 EF Core，集成常用组件，从0到1搭建。
前端：基于 小诺1.8 做适配，主技术栈：Vue2.6.x、Ant-Design-Vue
管理员：superAdmin 密码：123456
普通用户：user 密码：123456
注意：
原先的体验地址是 Linux 服务器，使用 Docker 方式部署。现新买了一个轻量型服务器，但是配置太低 Linux 使用 Docker 跑 SQL Server2019 怎么都跑不起来（要求 RAM 2000M以上），所以这台服务器是用的 Windows，简单部署，如体验有问题 Issue 告诉我，谢谢。
目前的部署方式是：Nginx 运行前端、dotnet 命令运行后端（写了一个 bat 脚本丢在自启目录），嗯，没有弄 IIS（主要还是嫌 IIS 安装慢）。
另外文档的部署方式，仍是 Linux 部署方法，如大家觉得 Jenkins、Docker、Linux 这些难以接受（毕竟 .NET 之前用的多是 Windows），有需要补充 Windows 的部署方式（分 IIS 方式部署、和 Nginx 方式）可以 Issue 告诉我，我会抽时间补充文档。
请参考使用手册
本人本机开发环境：
VS2022
VS Code
SQL Server2019 Express
.NET6
node 16.13.2
注：排名不分先后。
感谢这些优秀的开源项目！
-
依赖于抽象
依赖倒置原则，控制反转（IoC）
-
切面编程（AOP）
权限、日志、异常等通过过滤器（Filter）或中间件（Middleware）等实现，集中编程
-
可配置
-
自动注册
自动注册实体（Entity）、自动注册服务类（Service）等
主要分为三层：Interface表现层、Services服务层、Repository仓储层
Interface：Host依赖所有层，完成程序配置（如：Program.cs 中DI容器注入服务，中间件管道配置等）；Web API 配置路由，提供 API 接口，如果程序以后有迁移、或替换前端的情况，也可以在这里做一层适配器（注：API只是一种表现形式，也可以为MVC）
Services：所有的业务都在这一层。从仓储中读取数据模型（Models），进行业务操作，返回DTO（Data transfer objects）给表现层。
Repository：数据库访问。
通用的模块：Model、Common、Framework
Models：包含所有数据模型，如 Entity（对象数据库的数据表）、CacheItem缓存对象、EventModel事件模型等。
Common：集成常用组件，根据项目需要做相应配置；提供基础服务，如CurrentUser访问当前用户信息；提供静态帮助类，所有无状态的函数都归入此类，如GuidHelper.Next() 产生连续 Guid。
Framework：框架，比如引用ABP或Furion等框架，甚至是自己项目一些通用的能力，可以到处用的。
实际上，把 IServices 和 IRepository 此类接口层干掉了。
Models 则归入了对应的使用者里面，Framework 也没有。
Common # 基础设施：集成常用组件；提供基础服务；提供静态帮助类
Repository # 仓储层：数据库访问，数据库迁移
Services # 服务层：业务实现
WebApi # 表现层：完成程序配置；配置路由，提供API接口目录结构如下，更详细的结构，请查看文档。
├─config # 一些配置文件，如：redis 的配置文件
├─doc # 项目文档
├─web # 前端
├─webapi # 后端
├─Simple.Common # 基础设施
├─Simple.Repository # 仓储层
├─Simple.Services # 服务层
└─Simple.WebApi # 表现层- 组织架构
- 组织机构（organization）
- 岗位（position）
- 用户（user）
- 权限管理
- 应用（application）
- 菜单（menu）
- 角色（role）
- 开发管理
- 数据字典（dictionary、dictionaryItem）
- 日志管理
- 操作日志（log operating）
- 异常日志（log exception）
- 认证：集成Cookies、JWT；默认启用 JWT
- 授权：基于策略（Policy）的授权
- ORM：EF Core 的 Code First 模式
- 依赖注入：默认 DI 容器，实现自动注入
- 缓存：IDistributedCache，默认注入 Memory Cache，可替换 Redis
- 日志：NLog
- 事件总线：默认启用 BackgroupService，基于Channel 实现的单机版发布订阅；可替换为 Redis 的发布订阅（可用于分布式）；也可替换为 RabbitMQ 的发布订阅（可用于分布式）
- 定时任务：Quartz
- 数据验证：模型验证（Model validation）
- 对象映射：AutoMapper
答：一般项目中会如有 IRepository 和 IServices 这些个抽象层，主要是为了控制反转（IoC），实现项目各层之间解耦，最终目的就是为了“高内聚，低耦合”。
笔者认为，对于单体项目来说，做到高内聚即可，再追求完全的低耦合，会增加成本和困扰（举个简单的栗子：项目初期，业务大改是常有的事，改服务类的接口的事并不少见。除非说业务主体明确，需要修改的，并不是业务的接口，而是业务的具体实现）。
最后是这个项目，本就是为了追求最简三层单体。
答：简单的项目基本上是单数据库的，且 EF Core 已经实现了工作单元和仓储模式，可以不用再封装一层。
当然，笔者还是建议跟ABP框架那样再封装一层仓储，可以避免一些后续的开发运维问题（比如：系统迁移、重构等）。
- 提 Issue 请到 Gitee
如果这个项目对您有所帮助，可以扫下方二维码打赏一杯咖啡。
啊呸，我不喝咖啡，来杯可乐吧，啊哈哈哈。
