.NET 6+Vue前后端分离管理系统(开源)

前言

笔者前段时间搬砖的时候,有了一个偷懒的想法:如果开发的时候,简单的CURD可以由代码生成器完成,相应的实体、服务都不需要再做额外的注册,这样开发人员可以省了很多事。

于是就开了这个项目,期望实现这样的能力:业务人员只需关注实体的构建,业务服务的编写,以及路由的配置。

让业务的开发,变成简单的三步走:创建实体 >> 业务开发 >> 路由配置。

目前项目构思的绝大部分能力已完成(代码生成器、定时任务还未实现),现将项目发布,希望能对搬砖的大家伙有所帮助。

项目概述

前后端分离,使用 JWT 认证。

后端:基于 .NET 6 和 EF Core,集成常用组件,采用传统三层结构。

前端:基于 小诺1.8 做适配,主技术栈:Vue2.6.x、Ant-Design-Vue

体验地址

:12060/

管理员:superAdmin 密码:123456

普通用户:user 密码:123456

项目截图

图片[1]-.NET 6+Vue前后端分离管理系统(开源)-JieYingAI捷鹰AI

图片[2]-.NET 6+Vue前后端分离管理系统(开源)-JieYingAI捷鹰AI

快速开始

请参考项目文档:

小诺 snowy:

Admin.NET:

Blog.Core:

Adnc:

Furion:

ABP:

感谢这些优秀的开源项目!

基本设计思路

项目结构项目结构构思

图片[3]-.NET 6+Vue前后端分离管理系统(开源)-JieYingAI捷鹰AI

主要分为三层: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        # 表现层

业务能力系统能力项目亮点

EF Core 自动迁移脚本:

一些Q&A

1、为什么把 IServices 这些接口层给干掉了,仅留下实现层?

答:一般项目中会如有 IRepository 和 IServices 这些个抽象层,主要是为了控制反转(IoC),实现项目各层之间解耦,最终目的就是为了“高内聚,低耦合”。

笔者认为,对于单体项目来说,做到高内聚即可,再追求完全的低耦合,会增加成本和困扰(举个简单的栗子:项目初期,业务大改是常有的事,改服务类的接口的事并不少见。除非说业务主体明确,需要修改的,并不是业务的接口,而是业务的具体实现)。

最后是这个项目,本就是为了追求最简三层单体。

2、为什么不对仓储额外封装一层?

答:简单的项目基本上是单数据库的,且 EF Core 已经实现了工作单元和仓储模式,可以不用再封装一层。

当然,笔者还是建议跟ABP框架那样再封装一层仓储,可以避免一些后续的开发运维问题(比如:系统迁移、重构等)。

源码

Gitee:

Github:

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享
Death comes to all, but great achievements raise a monument which shall endure until the sun grows old.
死亡无人能免,但非凡的成就会树起一座纪念碑,它将一直立到太阳冷却之时