★ FEATURED ARTICLE 简介这是一套基于 WinForm 与 SQL Server 开发的外卖系统完整源码面向学习 C# 桌面应用开发、需要课程设计或毕业设计参考的开发者。项目按角色划分为用户端、商家端、骑手端与管理员四大模块用户端支持浏览商品、钱包、个人信息、跨店铺加入购物车、结算、进入店铺及我的订单商家端涵盖个人信息、商品管理、订单管理与骑手派单骑手端提供个人信息、订单查询与派单操作管理员则负责对各角色人员进行统一管理。压缩包共 392 个文件约 17.63MB以 109 个 cs 源码、51 个 resx 与 resources 资源文件、126 张 jpg 及 23 张 png 界面素材为主另含 sql 数据库脚本、config 配置、exe 可执行文件与 sln 解决方案结构完整。已有 556 人学习下载拿到即可运行适合对照源码理解多角色业务分层与数据库设计快速完成项目搭建与功能扩展。1. 从一堆缓存文件说起这套 WinFormSQL Server 外卖系统到底能跑出什么如果你从压缩包里解压出来第一眼看到的是一堆EHLM.csprojAssemblyReference.cache、DesignTimeResolveAssemblyReferencesInput.cache、EHLM.csproj.CoreCompileInputs.cache这类文件别慌这不是项目坏了而是 Visual Studio 在编译和设计器加载过程中留下的中间产物。真正要盯的是EHLM.csproj、EHLM.exe.config、App.config以及配套的数据库文件。这套资源是一份基于 C# WinForm 和 SQL Server 的外卖系统源码业务侧拆成了用户端、商家端、骑手端、管理员四个角色用户能跨店铺加购物车、走钱包结算、查历史订单商家能管商品、接订单、给骑手派单骑手能查单、接单、改状态管理员负责账号和基础数据维护。适合谁适合正在做 WinForm 课程设计、想找一个多角色权限订单状态机参考实现的同学也适合需要快速搭一个桌面端业务原型的小团队。它不是一个能直接上线的商业系统但作为「能跑起来、能改、能拆」的骨架价值在于把外卖业务里最绕的几块——跨店购物车、订单状态流转、角色权限隔离——用最朴素的 WinForm 控件和 SQL Server 表结构摆出来了。2. 环境准备与数据库还原把 SQL Server 和连接字符串先对齐2.1 确认 .NET Framework 版本和 SQL Server 实例这套项目用的是 WinForm大概率是 .NET Framework 4.x 而不是 .NET Core/.NET 5因为App.config和EHLM.exe.config同时存在这是典型的老式桌面项目配置方式。先打开EHLM.csproj看TargetFrameworkVersion节点常见是v4.7.2或v4.8。如果你机器上只装了 .NET 6/8 的 SDK是打不开这个项目的需要去 Visual Studio Installer 里勾选「.NET 桌面开发」工作负载并确认对应版本的 .NET Framework 开发工具包已安装。SQL Server 这边项目正文里说「文件带项目数据库」通常是一个.mdf文件或者一个.bak备份。如果是.mdf直接附加如果是.bak走还原。我一般会先确认本机 SQL Server 服务名常见默认实例是MSSQLSERVERExpress 版是SQLEXPRESS。打开 SSMS连上实例后先看一眼数据库列表避免还原时重名冲突。2.2 还原数据库的两种路径与连接字符串改法先看附加.mdf的方式。把.mdf和对应的.ldf放到一个固定目录比如D:\EHLM_DB\然后在 SSMS 里右键「数据库」→「附加」→「添加」选中.mdf。如果提示找不到日志文件删掉列表里的.ldf行让 SQL Server 自己重建日志即可。还原.bak更简单右键「数据库」→「还原数据库」→「设备」→ 选中.bak在「目标数据库」里填一个名字比如EHLMDB然后勾选「覆盖现有数据库」。数据库挂上之后回到项目里改连接字符串。App.config和EHLM.exe.config里通常各有一份connectionStrings节点两处都要改否则调试时用的是App.config发布后用的是EHLM.exe.config只改一处会出现「调试能跑、发布就报错」的经典翻车。connectionStrings !-- 把 Data Source 改成你的实例名Initial Catalog 改成实际数据库名 -- add nameEHLMConn connectionStringData Source.;Initial CatalogEHLMDB;Integrated SecurityTrue providerNameSystem.Data.SqlClient / /connectionStrings逻辑说明Data Source.表示本机默认实例如果是 Express 版要写成.\SQLEXPRESSIntegrated SecurityTrue走 Windows 身份验证省去账号密码如果你用的是 SQL Server 账号改成User IDsa;Password你的密码。参数上最容易错的是Initial Catalog必须和 SSMS 里看到的数据库名完全一致大小写不敏感但拼写不能差。改完先别急着 F5在 SSMS 里用同样的连接信息新建一个查询窗口能SELECT TOP 1 * FROM 某张表出结果再回 Visual Studio 跑能省掉一半「连不上数据库」的排查时间。2.3 首次编译前清掉缓存文件前面提到的那些.cache文件正常情况下 Visual Studio 会自己管理但如果你拿到的是别人打包好的目录obj和bin里可能残留了原机器的路径信息导致编译报「找不到引用」或「资源文件冲突」。稳妥做法是关闭 Visual Studio删掉obj和bin两个目录重新打开.csproj让它重新还原 NuGet 包并生成缓存。这一步不删也能跑但一旦报奇怪的引用错误先删缓存再试比逐条查引用快得多。3. 四端角色与订单状态机WinForm 里怎么把权限和流转拆干净3.1 用户端跨店铺购物车的数据结构设计用户端最值得看的是「跨店铺购物车」。普通单店购物车一张表就够跨店就必须在购物车表里同时记录店铺 ID 和商品 ID结算时按店铺分组生成子订单。常见做法是购物车表Cart里放UserID、ShopID、ProductID、Quantity、AddTime结算时先按ShopID分组每组生成一个订单主记录再挂订单明细。这样用户一次结算可以拆出多个店铺的订单每个店铺的商家只能看到自己那部分。// 按店铺分组生成订单核心是 GroupBy 之后逐组插入 var groups cartList.GroupBy(c c.ShopID); foreach (var g in groups) { int orderId orderDal.InsertOrder(userId, g.Key, g.Sum(x x.Quantity * x.Price)); foreach (var item in g) { orderDetailDal.Insert(orderId, item.ProductID, item.Quantity, item.Price); } }逻辑说明GroupBy的键是ShopID保证同一店铺的商品进同一张订单InsertOrder返回自增主键orderId再拿它去插明细。参数上要注意金额字段用decimal而不是doubleWinForm 里从 TextBox 取值时先decimal.TryParse再入库否则用户输入非数字会直接抛异常。钱包扣款要和订单插入放在同一个事务里否则会出现「订单生成了但钱没扣」或者反过来这种对账问题在课程设计里被问到的概率很高。3.2 商家端与骑手端派单和状态流转的边界商家端有「骑手派单」骑手端有「派单操作」这两端其实共享同一张订单表的同一个状态字段。订单状态一般设计成待接单 → 已接单 → 已派单 → 配送中 → 已完成中间可能还有「已取消」。商家点派单本质是把订单的RiderID字段填上同时状态从「已接单」推到「已派单」骑手点接单是把状态推到「配送中」。这里最容易出的问题是并发两个骑手同时看到同一单都点了接单。-- 用带状态条件的 UPDATE 做乐观锁影响行数为 0 说明被别人抢先了 UPDATE Orders SET RiderID RiderID, Status 配送中 WHERE OrderID OrderID AND Status 已派单 AND RiderID IS NULL;逻辑说明WHERE里带上Status 已派单和RiderID IS NULL只有满足条件的那一次更新才会成功ExecuteNonQuery返回 0 就提示「该单已被接走」。参数OrderID和RiderID从当前登录骑手的会话里取不要从界面控件取否则容易被改。这个写法比先查再更新可靠是 WinForm 里做状态流转的常用兜底。3.3 管理员端与权限隔离菜单和按钮的双层控制管理员端管各个人员本质是角色表的增删改查。权限隔离在 WinForm 里通常做两层登录后根据角色动态显示主菜单项这是第一层进入具体窗体后根据角色禁用或隐藏操作按钮这是第二层。只做菜单层不够因为用户可能通过其他入口打开窗体。常见做法是建一个静态的CurrentUser类存UserID、Role、ShopID商家才有每个窗体加载时读这个类来决定控件可见性。// 窗体加载时按角色控制按钮避免只靠菜单隐藏 private void OrderForm_Load(object sender, EventArgs e) { btnDispatch.Visible CurrentUser.Role Merchant; btnAccept.Visible CurrentUser.Role Rider; btnManage.Visible CurrentUser.Role Admin; }逻辑说明CurrentUser在登录成功时赋值整个进程生命周期内有效Visible控制比Enabled更彻底直接不给操作入口。参数上注意商家登录时要带上ShopID后续查订单、管商品都要用这个字段过滤否则商家会看到别家店铺的数据这是多店铺系统里最典型的越权坑。4. 避坑与排查这套源码跑不起来时先看这几条4.1 现象编译报「未能找到类型或命名空间」→ 原因NuGet 包没还原或引用路径失效 → 解决删 obj/bin 后重新还原拿到别人的项目packages目录可能没打包进来或者HintPath指向了原作者的绝对路径。先看EHLM.csproj里Reference节点的HintPath如果出现C:\Users\某某\...这种路径说明引用是坏的。解决办法是右键解决方案→「还原 NuGet 程序包」如果项目没用 NuGet 而是直接引 DLL就把缺失的 DLL 放回lib或packages目录再手动重新添加引用。4.2 现象登录时报「连接数据库失败」→ 原因连接字符串没改或 SQL Server 未启用 TCP/IP → 解决双配置改字符串并检查协议App.config和EHLM.exe.config两处都要改前面说过。另外 SQL Server 默认可能没开 TCP/IP在「SQL Server 配置管理器」里找到对应实例的协议把 TCP/IP 启用端口默认 1433。如果用的是 Express 版实例名要写.\SQLEXPRESS写成.会连到默认实例上自然连不上。4.3 现象跨店铺结算后订单金额对不上 → 原因分组时把运费或优惠算重了 → 解决把运费放在订单主表优惠按店铺分摊跨店结算最容易在金额上翻车。运费如果按整单算分组后每个子订单都加一次运费就重复了。常见做法是运费记在用户结算的总单上或者按店铺拆的时候只在一个子订单里收。优惠券同理要么按店铺金额比例分摊要么只作用于指定店铺。排查时先把购物车明细和生成的订单明细逐条对看是哪一步多算或少算。4.4 现象骑手端刷新后订单状态没变 → 原因界面没重新查库或用了缓存 DataSet → 解决每次操作后重新绑定数据源WinForm 里常用DataGridView绑DataSet如果只在窗体加载时查一次后续状态变了界面不会自动更新。解决方法是每次接单、派单成功后重新执行查询并重新绑定或者用BindingSource手动ResetBindings。别指望DataGridView自己感知数据库变化它不知道。4.5 现象发布后程序报「配置系统初始化失败」→ 原因EHLM.exe.config没跟着 exe 一起拷 → 解决确认输出目录里有同名 config发布或拷贝到别的机器时EHLM.exe.config必须和EHLM.exe在同一目录且文件名要和 exe 同名。如果只拷了 exe程序读不到连接字符串就会在启动时崩。检查bin\Debug或bin\Release目录确认 config 文件在。5. 进阶把订单状态流转做成可回放的状态日志这套源码里订单状态是直接改Orders表的Status字段简单直接但有个隐患一旦状态被改错你只知道当前是什么不知道什么时候、被谁改的。我在实际改这类项目时习惯加一张OrderStatusLog表每次状态变更都插一条记录字段包括OrderID、FromStatus、ToStatus、OperatorID、OperatorRole、ChangeTime。这样排查「这单为什么卡在配送中」时直接按OrderID查日志就能还原整条时间线比翻代码猜强得多。-- 状态日志表配合订单状态更新一起写 CREATE TABLE OrderStatusLog ( LogID INT IDENTITY(1,1) PRIMARY KEY, OrderID INT NOT NULL, FromStatus NVARCHAR(20), ToStatus NVARCHAR(20) NOT NULL, OperatorID INT NOT NULL, OperatorRole NVARCHAR(20) NOT NULL, ChangeTime DATETIME DEFAULT GETDATE() );逻辑说明FromStatus允许为空因为第一笔「待接单」没有前态OperatorRole记下是商家、骑手还是管理员操作的方便区分责任。写入时机放在每次UPDATE Orders SET Status成功之后用同一个事务包住保证订单状态和日志要么都成功要么都回滚。参数上ChangeTime用数据库默认值GETDATE()避免客户端时间不准。再进一步可以把状态流转规则做成一张配置表比如StatusTransition表里存FromStatus、ToStatus、AllowedRole更新前先查这张表判断当前角色能不能做这个流转。这样以后加「退款中」「已退款」这类状态只改配置不改代码。验证方法也简单手动在OrderStatusLog里插几条测试数据然后写一个查询按OrderID排序输出看时间线是否连续、有没有跳状态。如果发现从「待接单」直接跳到「配送中」说明中间某步没写日志回去检查对应的更新逻辑。从那以后我每次拿到这种带多角色状态流转的 WinForm 项目都先加日志表再动业务代码因为状态这东西一旦错了没有后悔药只能靠日志倒推。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
