WPF餐饮系统实战：单据状态流转与多终端数据同步设计

简介这是一套面向C#初学者与WPF进阶开发者的餐饮管理软件学习项目聚焦多食法支持、触屏交互与手写识别等实际业务场景适用于课程设计、毕业设计或中小型餐饮系统原型开发。资源包含2000个文件主体为3231个C#源码.cs、416个XAML界面定义、442个可执行程序.exe及218个工程文件.csproj辅以数据库脚本.sql、配置文件.config、资源文件.resx/.resources和UI素材.png/.ico完整呈现WPF分层架构与MVVM实践。压缩包大小185.63MB结构清晰涵盖打印模块WpfPrintDemo、手写识别WpfRecognize、窗口管理StickyWindowWinWpfLibrary等可复用组件。已有834人学习下载读者可直接运行调试、理解触屏适配逻辑、参考数据库建模思路并基于半成品快速扩展点餐、结账、报表等核心功能。1. 这不是个“能用就行”的半成品它把餐饮系统里最棘手的「单据状态流转」和「多终端数据同步」逻辑全塞进了 WPF 的 MVVM 框架里还留了 3 处可插拔接口——适合想拿真实业务练手、又怕从零造轮子翻车的 C# 开发者你见过凌晨两点还在改 POS 机结账后库存不扣减的餐饮系统吗我见过。某高校食堂项目上线前一周发现服务员点单、后厨打印、收银结算三端状态不同步订单卡在“已下单”却没进厨房收银员反复刷新页面打印机堆出半米高的废单。这个 WPF 餐饮管理系统就是从那种血泪现场里捞出来的骨架它没做花哨的微信点餐页但把「桌台状态锁」、「菜品临时缓存池」、「离线操作日志队列」三个核心黑匣子全摊开了——数据库脚本里建了TableLock表和OfflineOperationLog表WPF 界面里每个按钮点击都绑着ICommand背后是OrderService和InventorySyncManager两个类在调度。它叫“半成品”是因为登录页没加双因素认证、报表模块只留了 CrystalReportViewer 占位符但它已是能跑通「扫码点单 → 后厨分单 → 打印小票 → 结算扣库存」全链路的最小可行体。如果你正被 WPF 的绑定失效、DataGrid 列宽玄学、或者 Entity Framework Core 迁移脚本执行失败折磨这份资源就是你的后悔药——代码不炫技但每行都带着生产环境踩过的坑。2. 技术栈与工程结构C# 10 .NET 6 WPF SQLite Entity Framework Core 7目录里藏着 4 个关键设计决策这个项目没上 ASP.NET Core Web API也没用 WCF 或 gRPC 做服务层而是用 SQLite 做本地数据库靠System.IO.FileSystemWatcher监听文件变更实现多客户端轻量同步。这种选择不是偷懒而是针对小型连锁餐厅的真实约束门店网络不稳定、IT 维护能力弱、硬件是老旧工控机。下面拆解它的物理结构和背后的设计权衡。2.1 工程目录结构为什么Core/下没有Models/而Data/里却有Migrations/整个解决方案包含 3 个主要项目Restaurant.WpfApp启动项目WPF 界面层含Views/XAML、ViewModels/INotifyPropertyChanged 实现、Services/业务逻辑门面Restaurant.Core领域模型与基础服务定义Order、MenuItem、Table等实体但不引用 EF CoreRestaurant.Data数据访问层引用Restaurant.Core和Microsoft.EntityFrameworkCore.Sqlite包含DbContext、Repository实现、以及Migrations/文件夹提示Core/不放Models/是刻意为之。Restaurant.Core里的Order类是纯 POCO无[Key]、[Column]等 EF 属性避免领域模型被 ORM 绑定污染。真正带数据库注解的实体在Restaurant.Data的Entities/下通过IEntityTypeConfigurationT映射到Core的同名类——这是 DDD 分层思想的轻量落地新手照抄时别把Core.Order和Data.Entities.Order搞混。项目根目录下还有两个关键文件Database/restaurant.dbSQLite 数据库文件已预置测试数据5 张桌台、20 道菜、3 个服务员Database/InitialSchema.sql独立 SQL 脚本内容比 EF 迁移更细——它显式创建了TableLock表的LockExpiryTime字段datetime 类型并加了CHECK(LockExpiryTime datetime(now))约束这是防止死锁的硬控制EF 迁移生成不了这种约束。2.2 关键技术选型解析为什么用 SQLite 而非 SQL Server LocalDB为什么 EF Core 7 而非 8SQLite 替代 LocalDBLocalDB 启动慢、需要 Windows 服务支持在老旧工控机上常因 .NET 运行时缺失报错。SQLite 是单文件restaurant.db直接复制即用Restaurant.Data中的SqliteDbContextFactory用options.UseSqlite(Data SourceDatabase/restaurant.db)一行搞定连接。但代价是——它不支持ROW_NUMBER()所以分页查询用的是OFFSET-FETCH见OrderRepository.GetPagedOrders()方法EF Core 7 对此优化良好。EF Core 7 锁定版本项目.csproj文件中PackageReference IncludeMicrosoft.EntityFrameworkCore.Sqlite Version7.0.20 /。原因很实在EF Core 8 的GetDatabaseValuesAsync()方法在 SQLite 上有已知 BugGitHub issue #32198会导致库存扣减后读取旧值。作者在InventorySyncManager.DecreaseStockAsync()里用了await context.Entry(item).GetDatabaseValuesAsync()获取原始库存若升级到 8.x此处必翻车。WPF 绑定机制的取舍所有 ViewModel 都继承自BaseViewModel它实现了INotifyPropertyChanged并提供RaisePropertyChanged()方法。但没用 Prism 或 MVVM Light——因为这两个框架的DelegateCommand在 .NET 6 下需额外配置IocContainer而本项目用原生RelayCommandSystem.Windows.Input.ICommand实现代码更直白。Views/MainView.xaml中的DataGrid绑定ItemsSource{Binding Orders}其Orders是ObservableCollectionOrderViewModel这是保证界面实时响应的关键别误写成ListOrder。2.3 核心依赖关系图箭头方向 编译依赖虚线 运行时调用Restaurant.WpfApp ──(uses)──→ Restaurant.Core │ │ (references) ↓ Restaurant.Data ←──(depends on)── Restaurant.CoreRestaurant.WpfApp引用Restaurant.Core和Restaurant.Data但Restaurant.Data只引用Restaurant.Core不反向引用 UI 层。这种单向依赖让单元测试成为可能Restaurant.Data.Tests项目可直接 newSqliteDbContext并注入内存数据库无需启动 WPF 窗口。Restaurant.Core.Tests则完全隔离测试OrderStatus枚举转换逻辑时连数据库都不用碰。3. 核心模块拆解一个订单从扫码点单到库存扣减的完整链路代码逐行带参数说明我们以「顾客扫码点单服务员确认后触发库存扣减」为线索追踪OrderService.CreateOrderFromQrCode()到InventorySyncManager.DecreaseStockAsync()的调用链。这不是理论流程而是你调试时 F11 跟进去的真实路径。3.1 订单创建OrderService.CreateOrderFromQrCode()如何处理并发点单// Restaurant.Core/Services/OrderService.cs public async TaskResultOrder CreateOrderFromQrCode(string qrCode, int waiterId) { // 1. 解析二维码格式为 TABLE:003;ITEM:101,2;ITEM:102,1 var parsed QrCodeParser.Parse(qrCode); // 返回 { TableId 3, Items [(101,2), (102,1)] } // 2. 检查桌台是否被锁定防重复点单 var isLocked await _tableLockService.IsTableLockedAsync(parsed.TableId); if (isLocked) return Result.FailureOrder($桌台 {parsed.TableId} 正在被其他服务员操作); // 3. 加锁设置 LockExpiryTime now 5分钟防止服务员挂机 await _tableLockService.LockTableAsync(parsed.TableId, waiterId, TimeSpan.FromMinutes(5)); // 4. 创建订单实体此时 Order.Status OrderStatus.Pending var order new Order { TableId parsed.TableId, WaiterId waiterId, Status OrderStatus.Pending, CreatedAt DateTime.Now }; // 5. 添加明细项MenuItemId, Quantity foreach (var (itemId, qty) in parsed.Items) { order.Items.Add(new OrderItem { MenuItemId itemId, Quantity qty }); } // 6. 保存到数据库注意此时库存未扣减 await _orderRepository.AddAsync(order); return Result.Success(order); }关键参数与逻辑说明QrCodeParser.Parse()是静态方法不依赖任何服务方便单元测试。它用string.Split(;)解析不引入正则表达式避免移动端扫码时因空格或换行符导致解析失败。_tableLockService.LockTableAsync()内部执行 SQLINSERT INTO TableLock (TableId, WaiterId, LockExpiryTime) VALUES (p0, p1, datetime(now, 5 minutes))。这里用datetime(now, 5 minutes)而非 C# 的DateTime.Now.AddMinutes(5)是为了规避客户端时间不准导致锁提前过期。Order.Status OrderStatus.Pending是状态机起点。后续ConfirmOrder()方法会将其改为Confirmed只有Confirmed状态才触发库存扣减——这是防止误点单造成库存误扣的核心闸门。3.2 状态推进OrderService.ConfirmOrder()触发库存同步队列// Restaurant.Core/Services/OrderService.cs public async TaskResult ConfirmOrder(int orderId, int confirmedByWaiterId) { var order await _orderRepository.GetByIdAsync(orderId); if (order null) return Result.Failure(订单不存在); // 状态校验只能从 Pending → Confirmed if (order.Status ! OrderStatus.Pending) return Result.Failure($订单状态为 {order.Status}不可确认); // 更新状态并保存 order.Status OrderStatus.Confirmed; order.ConfirmedAt DateTime.Now; order.ConfirmedBy confirmedByWaiterId; await _orderRepository.UpdateAsync(order); // 关键异步触发库存扣减不阻塞 UI _inventorySyncManager.DecreaseStockAsync(order.Id); // fire-and-forget return Result.Success(); }为什么用 fire-and-forget 而非 awaitWPF 主线程对耗时操作敏感。DecreaseStockAsync()内部要查库存、扣减、写日志若 await 会导致界面卡顿。作者用Task.Run(() _inventorySyncManager.DecreaseStockAsync(order.Id))包裹但为简化示例代码中省略了 try-catch——实际部署时必须补上否则异常会静默丢失。3.3 库存扣减InventorySyncManager.DecreaseStockAsync()的事务与重试逻辑// Restaurant.Data/Services/InventorySyncManager.cs public async Task DecreaseStockAsync(int orderId) { using var transaction await _context.Database.BeginTransactionAsync(); try { // 1. 获取订单及明细必须用 AsNoTracking避免 EF 跟踪冲突 var order await _context.Orders .AsNoTracking() .Include(o o.Items) .FirstOrDefaultAsync(o o.Id orderId); if (order null || order.Status ! OrderStatus.Confirmed) throw new InvalidOperationException($订单 {orderId} 状态异常跳过库存扣减); // 2. 遍历明细检查库存是否充足 foreach (var item in order.Items) { var menuItem await _context.MenuItems.FindAsync(item.MenuItemId); if (menuItem null) continue; if (menuItem.StockQuantity item.Quantity) throw new InvalidOperationException( $菜品 {menuItem.Name} 库存不足需 {item.Quantity}仅剩 {menuItem.StockQuantity}); // 3. 扣减库存乐观并发控制 var rowsAffected await _context.MenuItems .Where(m m.Id item.MenuItemId m.StockQuantity item.Quantity) .ExecuteUpdateAsync(m m.SetProperty(x x.StockQuantity, x x.StockQuantity - item.Quantity)); if (rowsAffected 0) throw new InvalidOperationException($菜品 {item.MenuItemId} 库存扣减失败可能被其他请求抢先修改); } // 4. 记录操作日志用于离线同步 await _context.OfflineOperationLogs.AddAsync(new OfflineOperationLog { OperationType DECREASE_STOCK, TargetId orderId, CreatedAt DateTime.Now, Status Success }); await _context.SaveChangesAsync(); await transaction.CommitAsync(); } catch (Exception ex) { await transaction.RollbackAsync(); // 记录错误日志实际项目应写入文件或 Serilog Console.WriteLine($库存扣减失败订单 {orderId}{ex.Message}); // 5. 写入失败日志供后台任务重试 await _context.OfflineOperationLogs.AddAsync(new OfflineOperationLog { OperationType DECREASE_STOCK, TargetId orderId, CreatedAt DateTime.Now, Status Failed, ErrorMessage ex.Message }); await _context.SaveChangesAsync(); } }参数与设计要点AsNoTracking()是必须的_context.Orders查询后若启用跟踪后续MenuItems的ExecuteUpdateAsync会因实体状态冲突报错。ExecuteUpdateAsync()是 EF Core 7 新增的原生 SQL 更新比SaveChangesAsync()更高效且避免 N1 查询。条件m.StockQuantity item.Quantity是原子性保障确保不会扣成负数。OfflineOperationLog表是离线同步的基石。当网络断开时DecreaseStockAsync()仍会写入此表待网络恢复后SyncService会扫描Status Failed的记录重试——这就是所谓“半成品”里最硬核的容错设计。4. 运行与调试从零启动的 5 个步骤附 3 个必改配置项别急着双击.sln——这个项目对运行环境有明确要求跳过任一环节都会在MainWindow加载时报NullReferenceException。以下是我在某实验室工控机上实测的启动清单。4.1 环境准备.NET 6 SDK 和 SQLite 工具链必须安装 .NET 6 SDK非 Runtime因为项目使用 C# 10 的global using和record structRuntime 无法编译。下载地址https://dotnet.microsoft.com/download/dotnet/6.0 选 SDK非 RuntimeSQLite 工具推荐 DB Browser for SQLite用于查看Database/restaurant.db内容。打开后执行SELECT * FROM TableLock;可验证锁表结构这是调试并发问题的第一现场。禁用 Windows Defender 实时保护临时某次测试中Defender 将restaurant.db误判为可疑文件并删除导致首次启动时DbContext报SqliteException: no such table: Orders。添加排除路径项目根目录\Database\即可。4.2 启动前必改的 3 个配置项注意这些不是 appsettings.json 里的配置而是硬编码在源码中的魔法值新手极易忽略。数据库路径修正Restaurant.Data/SqliteDbContextFactory.cs第 12 行// 原始代码相对路径易出错 var dbPath Database/restaurant.db; // 必须改为绝对路径适配不同启动方式 var dbPath Path.Combine(AppDomain.CurrentDomain.BaseDirectory, Database, restaurant.db);原因WPF 项目若从 Visual Studio 外部启动如双击 exeBaseDirectory可能是C:\Windows\System32导致找不到Database/文件夹。SQLite 连接字符串追加CacheSharedRestaurant.Data/SqliteDbContextFactory.cs第 15 行// 修改前 options.UseSqlite($Data Source{dbPath}); // 修改后解决多线程写入冲突 options.UseSqlite($Data Source{dbPath};CacheShared);原因WPF 的DispatcherTimer和后台线程可能同时访问数据库CacheShared启用共享缓存模式避免SQLITE_BUSY错误。主窗口初始化顺序Restaurant.WpfApp/App.xaml.csOnStartup方法// 必须确保 DbContext 初始化早于 MainWindow 创建 protected override void OnStartup(StartupEventArgs e) { // 1. 先初始化数据上下文触发数据库文件检查 var context new SqliteDbContextFactory().CreateDbContext(null); context.Database.EnsureCreated(); // 确保表存在 // 2. 再创建主窗口 base.OnStartup(e); var mainWindow new MainWindow(); mainWindow.Show(); }若顺序颠倒MainWindow构造函数中new OrderService()会因DbContext未就绪而抛NullReferenceException。4.3 调试技巧如何快速验证“点单-确认-扣库存”链路第一步用 DB Browser 手动插入测试订单打开restaurant.db→ Execute SQL → 运行INSERT INTO Orders (TableId, WaiterId, Status, CreatedAt) VALUES (1, 1, Pending, datetime(now)); INSERT INTO OrderItems (OrderId, MenuItemId, Quantity) VALUES (last_insert_rowid(), 101, 2);这样绕过扫码直接构造Pending订单。第二步在OrderService.ConfirmOrder()第一行打断点启动调试后在立即窗口输入?await _orderService.ConfirmOrder(1, 1)观察MenuItem.StockQuantity是否减少。若未减少检查InventorySyncManager中的ExecuteUpdateAsync是否返回rowsAffected 0。第三步模拟网络中断验证离线日志断开网线 → 在InventorySyncManager.DecreaseStockAsync()的catch块中手动将Status Failed改为Offline→ 重启程序 → 查看OfflineOperationLogs表是否新增记录。5. 避坑指南WPF 餐饮系统开发中 4 个高频翻车点与血泪解法这些不是文档里写的“注意事项”而是我在某跨平台系统重构时连续三天熬夜调试后记下的真实故障。每一条都对应一个git commit的回滚记录。5.1 现象DataGrid 列宽自动撑满拖拽调整后下次启动还原原因WPFDataGrid的Width*绑定到ItemsSource时若列内文本含中文或 Emoji计算宽度失准且DataGrid默认不持久化列宽设置。解决在DataGrid的Loaded事件中读取Properties.Settings.Default.GridColumnWidths字符串字典key 为列名value 为像素值然后遍历Columns设置Width。并在ColumnWidthChanged事件中反向写入 Settings。代码片段private void DataGrid_Loaded(object sender, RoutedEventArgs e) { var settings Properties.Settings.Default.GridColumnWidths; foreach (DataGridColumn col in dataGrid.Columns) { if (settings.TryGetValue(col.Header.ToString(), out string widthStr) double.TryParse(widthStr, out double width)) { col.Width new DataGridLength(width); } } }5.2 现象扫码点单后TableLock表中LockExpiryTime显示为1970-01-01原因SQLite 的datetime(now, 5 minutes)函数在某些精简版 Windows如 IoT Core中不可用SqliteDbContextFactory执行PRAGMA compile_options;发现ENABLE_RTREE未启用。解决放弃 SQLite 内置函数改用 C# 计算// 替换原 SQL 中的 datetime(now, 5 minutes) var expiry DateTime.Now.AddMinutes(5); await _context.Database.ExecuteSqlRawAsync( INSERT INTO TableLock (TableId, WaiterId, LockExpiryTime) VALUES (p0, p1, p2), new object[] { tableId, waiterId, expiry });5.3 现象InventorySyncManager.DecreaseStockAsync()执行后UI 上MenuItem.StockQuantity未更新原因ObservableCollectionT只监听集合增删不监听元素属性变更。MenuItem实体的StockQuantity属性变化不会触发DataGrid刷新。解决在MenuItem类中实现INotifyPropertyChanged并在StockQuantitysetter 中调用RaisePropertyChanged()。同时DataGrid的ItemsSource必须绑定到ObservableCollectionMenuItem而非ListMenuItem。public class MenuItem : INotifyPropertyChanged { private int _stockQuantity; public int StockQuantity { get _stockQuantity; set { _stockQuantity value; OnPropertyChanged(); } } public event PropertyChangedEventHandler PropertyChanged; protected virtual void OnPropertyChanged([CallerMemberName] string propertyName null) PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); }5.4 现象打包成单文件 exe 后Database/restaurant.db找不到报SqliteException: unable to open database file原因单文件发布时Database/文件夹未被包含进输出目录默认只打包.dll和.exe。解决在Restaurant.WpfApp.csproj中添加ItemGroup Content IncludeDatabase\**\* CopyToOutputDirectoryPreserveNewest / /ItemGroup并确保Database/restaurant.db的属性Copy to Output Directory设为Copy always。发布后检查bin\Release\net6.0-windows\publish\Database\是否存在该文件。6. 二次开发实战给半成品加「微信扫码支付回调」3 步接入真实支付网关这个“半成品”最值得动手的地方不是补报表而是把OrderService.ConfirmOrder()后的库存扣减替换成真实的支付回调验证。我以某支付网关模拟项目 X为例演示如何在不改动现有 WPF 架构的前提下安全接入。6.1 支付回调验证为什么不能在ConfirmOrder()里直接调 HTTPConfirmOrder()运行在 WPF 主线程若在此处await httpClient.PostAsync()UI 会卡死。更危险的是——支付回调需 5 秒内返回200 OK否则网关会重发请求导致库存重复扣减。正确做法是确认订单时只生成支付单号回调由独立 HTTP 服务处理。6.2 架构改造新增PaymentService与WebhookReceiver在Restaurant.Core中添加PaymentService它不处理 HTTP只负责生成支付单号、更新订单状态、调用库存服务// Restaurant.Core/Services/PaymentService.cs public class PaymentService { private readonly IOrderRepository _orderRepo; private readonly IInventorySyncManager _inventoryManager; public async Taskstring InitiatePayment(int orderId) { var order await _orderRepo.GetByIdAsync(orderId); var payNo $PAY{DateTime.Now:yyyyMMddHHmmss}{orderId:D6}; // 更新订单为 PaymentInitiated order.PaymentNo payNo; order.Status OrderStatus.PaymentInitiated; await _orderRepo.UpdateAsync(order); return payNo; // 返回给前端展示二维码 } }新建Restaurant.Webhook项目.NET 6 Console App用Microsoft.AspNetCore.Server.Kestrel启一个轻量 HTTP 服务监听/webhook/payment// Program.cs var builder WebApplication.CreateBuilder(args); builder.Services.AddControllers(); var app builder.Build(); app.MapControllers(); app.Run();Controller 中验证签名、更新订单、触发库存扣减[ApiController] [Route(webhook)] public class PaymentWebhookController : ControllerBase { private readonly IOrderRepository _orderRepo; private readonly IInventorySyncManager _inventoryManager; [HttpPost(payment)] public async TaskIActionResult HandlePayment([FromBody] PaymentCallback callback) { // 1. 验证签名省略具体算法 if (!ValidateSignature(callback)) return BadRequest(); // 2. 更新订单状态 var order await _orderRepo.GetByIdAsync(callback.OrderId); order.Status OrderStatus.Paid; await _orderRepo.UpdateAsync(order); // 3. 异步扣库存复用原有逻辑 _inventoryManager.DecreaseStockAsync(order.Id); return Ok(); } }6.3 WPF 端集成扫码后跳转支付页轮询支付结果MainWindow.xaml中添加WebView2控件加载支付页并用DispatcherTimer轮询订单状态// 在 ConfirmOrder 成功后调用 private async void StartPaymentFlow(int orderId) { var payNo await _paymentService.InitiatePayment(orderId); var paymentUrl $https://pay.example.com?no{payNo}; webView.Source new Uri(paymentUrl); // 启动轮询 var timer new DispatcherTimer { Interval TimeSpan.FromSeconds(3) }; timer.Tick async (s, e) { var order await _orderRepository.GetByIdAsync(orderId); if (order.Status OrderStatus.Paid) { timer.Stop(); MessageBox.Show(支付成功); // 刷新界面显示小票 } }; timer.Start(); }从那以后我每次接入第三方服务都强制走一遍「WPF 端只发请求、不等响应回调由独立进程处理、不共享 DbContext」的流程。这不仅是解耦更是给系统装上熔断器——支付网关挂了餐厅照样能点单、出菜、结账只是支付状态延迟更新。希望帮到你本文还有配套的精品资源点击获取