基于.NET6 的简单三层管理系统
前言
笔者前段时间搬砖的时候，有了一个偷懒的想法：如果开发的时候，简单的 CURD 可以由代码生成器完成，相应的实体、服务都不需要再做额外的注册，这样开发人员可以省了很多事。
于是就开了这个项目，期望实现这样的能力：业务人员只需关注实体的构建，业务服务的编写，以及路由的配置。
让业务的开发，变成简单的三步走：创建实体 >> 业务开发 >> 路由配置。
目前项目构思的绝大部分能力已完成（代码生成器、定时任务还未实现），现将项目发布，希望能对搬砖的大家伙有所帮助。
项目概述
前后端分离，使用 JWT 认证。
后端：基于 .NET6 和 EF Core，集成常用组件，采用传统三层结构。
前端：基于 小诺1.8 做适配，主技术栈：Vue2.6.x、Ant-Design-Vue
体验地址
管理员：superAdmin 密码：123456
普通用户：user 密码：123456
快速开始
请参考项目文档： 使用手册
参考项目
注：排名不分先后。
感谢这些优秀的开源项目！
基本设计思路
依赖于抽象
依赖倒置原则，控制反转（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 也没有。
目录结构如下，更详细的结构，请查看文档。
业务能力
组织架构组织机构（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
项目亮点
一些 Q&A
为什么把 IServices 这些接口层给干掉了，仅留下实现层？
答：一般项目中会如有 IRepository 和 IServices 这些个抽象层，主要是为了控制反转（IoC），实现项目各层之间解耦，最终目的就是为了“高内聚，低耦合”。
笔者认为，对于单体项目来说，做到高内聚即可，再追求完全的低耦合，会增加成本和困扰（举个简单的栗子：项目初期，业务大改是常有的事，改服务类的接口的事并不少见。除非说业务主体明确，需要修改的，并不是业务的接口，而是业务的具体实现）。
最后是这个项目，本就是为了追求最简三层单体。
为什么不对仓储额外封装一层？
答：简单的项目基本上是单数据库的，且 EF Core 已经实现了工作单元和仓储模式，可以不用再封装一层。
当然，笔者还是建议跟 ABP 框架那样再封装一层仓储，可以避免一些后续的开发运维问题（比如：系统迁移、重构等）。
源码
需要Java资料或者咨询可加我v ： Jimbye 2022.08.16 加入
还未添加个人简介
评论