简介这套C#企业后台管理系统是基于微软.NET平台与ASP.NET技术开发的B/S架构完整源码覆盖用户管理、权限分配、数据报表和流程审批等核心业务模块适合需要学习企业级管理系统设计或正在搭建内部管理平台的.NET开发者。压缩包共909个文件大小约104.86MB主要包含C#业务逻辑代码、cshtml视图页面、JavaScript与CSS前端资源、DLL组件以及SQL数据库创建脚本前后端代码和数据层脚本一次配齐。资源已有2298人学习下载获得一定关注。系统附带数据库字段说明可对照理解表结构设计项目整体采用分层架构从仓储层、应用服务到页面控制器均有示例代码便于读者追踪一个完整功能的实现链条。资源中涉及ASP.NET MVC设计模式、数据库范式及权限控制思路读者不仅能直接运行调试还能基于现有模块扩展新功能是一份适合用于项目实战和进阶学习的综合参考资料。1. 我接手过一套写到一半的 C# 企业后台管理系统先说结论某制造企业曾经有三套小工具分别管订单、库存和员工考勤月底对账要翻半小时聊天记录。后来把用户角色、菜单权限、操作日志、数据字典全部收进同一个后台新功能上线速度反而提上来了。这就是“C# 完整的企业后台管理系统”要解决的问题用 C# 从零搭一套能直接复用的后台骨架它包含哪些模块、按什么顺序落地、哪里最容易踩坑。这套东西最适合正在做内部管理系统、想快速出活又要留扩展余地的团队也适合准备接手老旧后台项目、想整体重构的开发者。下面从技术选型开始每一章都会落到具体命令和代码照着走就能在本机跑起来。2. 技术选型与工程结构为什么是 ASP.NET Core EF Core2.1 小团队自建后台选型先看维护成本企业内部后台管理系统最常见的技术路线是 ASP.NET CoreMVC 或 Razor Pages EF Core SQL Server/PostgreSQL。我一般会选 Razor Pages 或 MVC而不是 Blazor Server。Blazor Server 的实时交互确实爽但部署模型多一套 SignalR 长连接很多运维同事不熟悉出了问题排查成本高。内部后台没有强交互诉求服务端渲染的 Razor Pages 上手最快遇到问题资料也好找。前后端分离也不是不能做只是多出一层接口联调和权限同步成本。如果团队里前端资源紧张强行上 Vue/React 反而拖慢进度。后台管理系统的核心是表单、表格、权限控制服务端渲染足够撑住 90% 的页面。方案适合场景维护成本备注ASP.NET Core MVC传统后台、需要大量服务端渲染低生态最成熟Razor Pages页面简单、带表单为主最低页面自带模型绑定Blazor Server高交互后台、团队熟悉 C#中需要维护长连接Web API 前端框架要开放接口、多端共用高权限和联调成本都上浮ORM 选型上EF Core 在增删改查、迁移、导航属性上省很多事。企业后台管理系统绝大多数页面是 CRUD模型和表一一对应EF Core 代码量最少。Dapper 适合复杂报表查询但后台管理系统的复杂查询一般集中在报表页可以单独开一条查询通道主体还是用 EF Core。我见过团队为了“性能”全项目上 Dapper结果每个页面写一堆 SQL后期加个字段要改五六处维护成本反而上去了。2.2 工程目录与最小可运行骨架用 dotnet CLI 就能把解决方案建出来不需要依赖 Visual Studiodotnet new sln -n EnterpriseAdmin dotnet new webapp -n EnterpriseAdmin.Web -o src/EnterpriseAdmin.Web dotnet new classlib -n EnterpriseAdmin.Core -o src/EnterpriseAdmin.Core dotnet new classlib -n EnterpriseAdmin.Infrastructure -o src/EnterpriseAdmin.Infrastructure dotnet sln EnterpriseAdmin.sln add src/EnterpriseAdmin.Web src/EnterpriseAdmin.Core src/EnterpriseAdmin.Infrastructure dotnet add src/EnterpriseAdmin.Web reference src/EnterpriseAdmin.Core src/EnterpriseAdmin.Infrastructure dotnet add src/EnterpriseAdmin.Infrastructure reference src/EnterpriseAdmin.Core命令里的-n指定项目名-o指定输出目录。Web 层引用 Core 和 InfrastructureInfrastructure 引用 Core这样 Web 层不会直接碰数据库细节。最后一条命令把 Infrastructure 的引用指向 Core保证依赖方向是单向的。建完之后的目录结构是这样的src/ EnterpriseAdmin.Web/ # 页面、控制器、启动配置 EnterpriseAdmin.Core/ # 实体、接口、权限常量、DTO EnterpriseAdmin.Infrastructure/ # EF Core 实现、仓储、日志写入把 EF Core 实现在 Infrastructure 里、接口定义在 Core 里是这套分层的关键。将来换数据库、换缓存实现Web 层代码不用动。很多小项目一开始图省事把 DbContext 直接放在 Web 项目里结果项目一大迁移文件、实体和控制器揉在一起后面改一次结构就是一次大扫除。我建议从第一天就按三层来放。2.3 依赖注入与启动配置Program.cs 里要注册 DbContext 和各业务服务。最小配置长这样builder.Services.AddDbContextAdminDbContext(options options.UseSqlServer(builder.Configuration.GetConnectionString(Default))); builder.Services.AddScopedIUserRepository, UserRepository();AddDbContext默认生命周期是 Scoped意思是每次 HTTP 请求内共用一个实例这正好匹配 EF Core 的工作单元设计。AddScoped同理保证每次请求拿到的仓储对象和 DbContext 是同一个避免出现跟踪实体的状态冲突。连接字符串放在 appsettings.json 的 ConnectionStrings 节点下不要写死在代码里尤其别提交到代码仓库。如果项目后面要加缓存、加消息队列就往 Infrastructure 层加实现Web 层只依赖接口。三层架构在后台管理系统这个规模下足够清晰不需要再引入 Application 层增加概念负担。3. 数据库设计与核心表落地用户、角色、菜单、日志3.1 后台系统的最小表结构清单一套能跑起来的企业后台管理系统至少要覆盖用户、角色、菜单、日志四类数据。用户和角色是多对多角色和菜单是多对多所以除了三张主表还要两张关联表。操作日志独立一张表数据字典再占两张表。表名用途核心字段User后台用户用户名、密码哈希、显示名、启用状态Role角色角色名、权限描述Menu菜单/按钮菜单名、路由路径、权限码、类型、排序UserRole用户-角色关联用户ID、角色IDRoleMenu角色-菜单关联角色ID、菜单IDOperationLog操作日志用户ID、动作、方法、状态码、耗时DictType / DictItem数据字典字典类型、字典项键值主键我一般用 long 自增列内部系统导出 Excel 时不会像 Guid 那样显示一长串排序也直观。每个表加上 CreatedAtUtc 和软删除标记方便审计和恢复数据。菜单表里用 PermissionCode 字段存权限码不要用层级字段硬编码树结构否则后面调菜单顺序和按钮权限会非常痛苦。3.2 用 EF Core Code First 落库实体、DbContext 与迁移实体类定义放在 Core 项目里先写用户实体public class User { public long Id { get; set; } public string UserName { get; set; } string.Empty; public string PasswordHash { get; set; } string.Empty; public string DisplayName { get; set; } string.Empty; public bool Enabled { get; set; } true; public DateTime CreatedAtUtc { get; set; } public ListRole Roles { get; set; } new(); }PasswordHash存的是不可逆的哈希结果不是明文。Enabled做软禁用比直接删用户安全。角色和菜单实体也放在同一目录代码风格保持一致。DbContext 放在 Infrastructure 项目里配置多对多关系和字段长度public class AdminDbContext : DbContext { public AdminDbContext(DbContextOptionsAdminDbContext options) : base(options) { } public DbSetUser Users SetUser(); public DbSetRole Roles SetRole(); public DbSetMenu Menus SetMenu(); public DbSetOperationLog OperationLogs SetOperationLog(); protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.EntityUser() .HasMany(u u.Roles) .WithMany(r r.Users) .UsingEntity(j j.ToTable(UserRoles)); modelBuilder.EntityRole() .HasMany(r r.Menus) .WithMany(m m.Roles) .UsingEntity(j j.ToTable(RoleMenus)); modelBuilder.EntityMenu() .Property(m m.Path) .HasMaxLength(200); } }UsingEntity指定关联表名否则 EF Core 会默认生成一长串关联表名后面写 SQL 查询时很难受。菜单路径限制 200 长度防止有人填一个超长的路由把界面撑爆。然后执行迁移dotnet tool install --global dotnet-ef dotnet ef migrations add InitialCreate --project src/EnterpriseAdmin.Infrastructure --startup-project src/EnterpriseAdmin.Web dotnet ef database update --project src/EnterpriseAdmin.Infrastructure --startup-project src/EnterpriseAdmin.Web--project指定包含 DbContext 的程序集--startup-project指定启动项目因为连接字符串在启动项目的 appsettings.json 里。如果提示找不到 DbContext八成是启动项目没注册服务或者没有引用 EF Core 的 SQL Server 包先dotnet build再执行。3.3 种子数据与数据字典初始化系统第一次跑起来至少要有一个管理员角色和一个管理员账号。我用一个手动 Seed 方法在应用启动时执行public static class DbSeeder { public static void Run(AdminDbContext db) { if (db.Roles.Any()) return; db.Roles.Add(new Role { Name Admin }); db.Menus.Add(new Menu { Name 系统管理, Path /system, PermissionCode system:view, Sort 1 }); db.SaveChanges(); } }种子数据的思路是“只补最小必需项”不要在启动时写一堆 if 判断和业务数据否则每次部署都会偷偷改数据库。数据字典我习惯拆成 DictType 和 DictItem 两张表性别、状态、通知类型这些下拉选项都从字典表读取不要散落在前端页面里写死。菜单表里用 Type 字段区分“目录/菜单/按钮”。目录只做分组菜单有跳转路径按钮没有路径但有 PermissionCode。这样设计和实现都简单按钮级权限最终只看权限码是否在用户 Claim 里。4. 从登录到鉴权把 RBAC 权限和审计日志接进系统4.1 Cookie 认证与登录接口企业内部后台系统我一般用 Cookie 认证而不上 JWT。原因很简单后台系统是单域部署不需要跨域携带令牌Cookie 方案天然防 CSRF配合防伪标记刷新过期逻辑也好控制。Program.cs 里配置builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) .AddCookie(options { options.LoginPath /Account/Login; options.ExpireTimeSpan TimeSpan.FromHours(8); options.SlidingExpiration true; });LoginPath指未认证时跳转的登录页ExpireTimeSpan设置 Cookie 有效期SlidingExpiration是滑动过期用户连续操作就不需要反复登录。登录接口的核心逻辑是校验密码、写 Claim、签名 Cookie[HttpPost] public async TaskIActionResult Login(string userName, string password) { var user await _userRepo.GetByNameAsync(userName); if (user null || !VerifyPassword(password, user.PasswordHash)) return Unauthorized(); var claims new ListClaim { new(ClaimTypes.NameIdentifier, user.Id.ToString()), new(ClaimTypes.Name, user.DisplayName) }; claims.AddRange(await _userRepo.GetPermissionClaimsAsync(user.Id)); var identity new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme); await HttpContext.SignInAsync( CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(identity)); return RedirectToAction(Index, Home); }登录时就把权限码放进 Claim 里后面做按钮级鉴权不用每次查数据库。密码校验用 PBKDF2 或 BCrypt千万不要用 MD5 或者 SHA256 裸哈希数据库被导出等于密码全部泄露。4.2 用自定义权限处理器做菜单和按钮级鉴权角色判断太粗两个角色可能只能差一个按钮权限所以我用“权限码”做细粒度控制。先定义权限常量public static class Permissions { public const string UserView user:view; public const string UserEdit user:edit; public const string UserDelete user:delete; }权限码的格式是“资源:动作”可读性好也方便在菜单表里维护。自定义 AuthorizationHandler 来解析这些权限码public class PermissionHandler : AuthorizationHandlerPermissionRequirement { protected override Task HandleRequirementAsync( AuthorizationHandlerContext context, PermissionRequirement requirement) { var permissionCodes context.User.FindAll(permission).Select(c c.Value); if (permissionCodes.Contains(requirement.PermissionCode)) context.Succeed(requirement); return Task.CompletedTask; } }在 Program.cs 里注册策略时把每个权限码绑定到对应策略名控制器或页面上直接写[Authorize(Policy Permissions.UserEdit)]。这样 RABC 的“角色-菜单-权限码”链路就完整了角色关联菜单菜单携带权限码登录时权限码落进 Claim鉴权时从 Claim 里取。4.3 一个过滤器把操作日志全量记下来审计日志不能靠每个人在 Controller 里手动写那样一定会漏。我习惯用一个全局过滤器统一收集public class OperationLogFilter : IAsyncActionFilter { public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next) { var sw Stopwatch.StartNew(); var result await next(); sw.Stop(); var log new OperationLog { UserId context.HttpContext.User.FindFirst(ClaimTypes.NameIdentifier)?.Value ?? anonymous, Action ${context.RouteData.Values[controller]}/{context.RouteData.Values[action]}, Method context.HttpContext.Request.Method, StatusCode result.HttpContext.Response.StatusCode, ElapsedMs sw.ElapsedMilliseconds, CreatedAtUtc DateTime.UtcNow }; // 写入数据库 } }IAsyncActionFilter在 Action 执行前后都能拿到上下文所以既能记请求参数又能记耗时。日志写入用异步接口不要阻塞主请求。注册成全局过滤器后所有 Controller 的请求都会被记录不需要单独改页面代码。5. 本地跑通与部署避坑5 个让后台管理系统翻车的常见问题5.1 本地开发阶段的三处高频翻车坑 1迁移命令报“Unable to create a DbContext”现象执行dotnet ef database update时直接报错说不能创建 DbContext 实例。原因通常是启动项目没有注册 DbContext或者连接字符串没读到。解决先去 Program.cs 确认AddDbContext已经调用再确认启动项目是EnterpriseAdmin.Web最后检查 appsettings.json 里的连接字符串名字是不是和代码里一致。还有一个隐蔽点如果 DbContext 构造函数什么都没做但启动项目没有安装 Provider 包也会报这个错。坑 2登录成功后一刷新就回到登录页现象登录跳转首页正常点任何菜单也正常但只要刷新浏览器就掉登录态。原因Cookie 默认有效期是 Session浏览器关掉就失效另一种情况是开发机重新编译导致 Data Protection 密钥环变化旧 Cookie 全部作废。解决设置ExpireTimeSpan为固定时长同时在 ConfigureServices 里配置持久化密钥环。开发环境偷懒可以不配但测试环境一定要配否则每次重启进程都要重新登录。坑 3接口返回 JSON 时报“循环引用”现象返回用户列表时每条用户都带出角色列表角色列表里又带出用户列表序列化直接死循环。原因实体导航属性互相引用序列化时无限递归。解决写 DTO 映射不直接返回实体。用 AutoMapper 也好手写映射也好总之不要让实体直接暴露给前端。用ReferenceHandler.IgnoreCycles能临时压住报错但返回的数据结构里会多出很多嵌套前端也不好用。5.2 部署到服务器后的两个隐蔽坑坑 4部署后刷新子页面返回 404现象本地运行一切正常放到 Linux 服务器上用 Web Server 转发后打开首页没问题刷新/system/user这种二级路径就直接 404。原因转发层把请求按文件路径去找了没找到就返回 404没有回退到应用入口。解决在转发配置里加一条规则把所有非静态文件请求都转发到入口地址同时确认应用里启动路径配置正确。排查时先分清楚是应用本身 404 还是转发层 404别在应用里找半天。坑 5日志时间比北京时间少 8 小时现象操作日志里白天 14 点的操作记录显示为 06 点。原因服务器时区是 UTC代码里用了DateTime.Now而系统设计时统一的是DateTime.UtcNow。解决所有写日志、写创建时间的地方统一用DateTime.UtcNow落库展示时再按当前用户时区转换。千万别在写库时用本地时间、读库时又转 UTC两头不一致查数据最痛苦。6. 进阶技巧用权限矩阵脚本快速验证接口级鉴权权限功能写完不是终点每次加菜单、改角色最容易漏掉接口权限。手动开页面点一遍费时间还容易漏。我的做法是从菜单表导出“权限码-角色”矩阵再用脚本批量请求受保护接口根据 HTTP 状态码判断有没有越权。先导出一份权限矩阵SELECT m.PermissionCode, r.Name AS RoleName FROM Menus m JOIN RoleMenus rm ON m.Id rm.MenusId JOIN Roles r ON rm.RolesId r.Id WHERE m.PermissionCode IS NOT NULL;结果保存成 CSV 文件一行是一条角色能访问的权限码。然后跑脚本#!/usr/bin/env bash BASE_URLhttp://localhost:5000 COOKIE_FILE/tmp/admin.cookies # 用管理员账号登录拿到登录态 curl -s -c $COOKIE_FILE -X POST $BASE_URL/Account/Login \ -d userNameadminpasswordyourpass -o /dev/null # 遍历权限矩阵期望所有接口返回 200 while IFS, read -r permission_code role_name; do path$(echo $permission_code | tr : /) code$(curl -s -b $COOKIE_FILE -o /dev/null -w %{http_code} $BASE_URL/aop$path) if [ $code ! 200 ]; then echo FAIL: $role_name - $path (HTTP $code) fi done role_permissions.csv脚本里把权限码user:view转成请求路径/aop/user/view实际项目中可以在测试环境专门映射一套按权限码命名的测试接口。脚本只是兜底不替代权限设计。它可以查出两类问题一是该有权限的角色拿到 403说明权限配少了二是不该有权限的角色拿到 200说明权限配多了。更严格的做法是切换成不同角色的登录态再跑一遍矩阵比对结果。我之前维护的一套后台就是上线前手动测过主菜单结果某个版本加了一个批量删除按钮忘了给角色授权直到业务同事反馈才发现。后来我把这个矩阵脚本接进发布流水线每次权限变更自动跑一遍这类问题基本绝迹。希望帮到你。本文还有配套的精品资源点击获取
