简介这是一套面向C#桌面开发者的MES制造执行系统实战项目源码采用WPF框架构建适合具备一定C#与XAML基础、希望深入理解工业软件界面与业务架构的开发者参考学习。资源包共315个文件约11.95MB其中88个cs源文件承载核心业务逻辑62个dll与7个nupkg提供依赖组件45个xml、12个config及1个settings负责配置管理10个xaml与18个baml构成WPF界面与样式资源另有12个exe、若干log、pdb、manifest等运行与调试文件整体结构贴近真实工程。项目围绕库位展示、主窗口、按钮样式、TabControl等模块展开可帮助读者梳理WPF在MES场景下的页面组织、样式复用与数据交互思路。目前已有736人学习下载适合作为课程设计、毕业设计或企业级桌面应用改造的参考蓝本。1. 从一次产线数据刷新卡顿说起这套 C# MESWPF 资源到底能干什么去年帮一个做离散制造的朋友看他们车间的报工终端界面是 WPF 写的数据源是本地 MES 服务。现象很典型操作工扫码报工后界面要等两三秒才刷新工单状态偶尔直接卡死。排查下来不是数据库慢是 UI 线程里同步调了服务端接口加上工单列表用了默认的虚拟化配置几千条记录一次性渲染。这类问题在 WPF 做 MES 客户端的场景里几乎躲不掉——MES 要求实时反映产线状态WPF 又是个对线程和绑定格外敏感的框架两者凑一起写得好是流畅的车间看板写不好就是操作工嘴里的“破电脑”。这套 C# MESWPF 资源核心就是一套面向制造执行场景的桌面客户端实现覆盖工单管理、报工采集、设备状态监控、物料追溯这几块 MES 里最常落地的模块。技术栈是 .NET WPF服务端走 C# 后端接口客户端用 MVVM 分层。它适合两类人一是刚接手 MES 客户端维护、需要一份能跑通的参考实现的开发者二是想从 WinForm 转 WPF 做工业软件、但不知道 MVVM 在真实业务里怎么落地的熟手。下面按“资源是什么、怎么跑起来、坑在哪、怎么用顺”这条线拆开讲。2. 拆开这套 MESWPF 的工程结构MVVM 分层与模块划分拿到一份 C# MES 客户端源码第一件事不是急着 F5而是先看清它的分层。工业软件的代码组织直接决定了你后续改需求时会不会牵一发动全身。这套资源的目录结构是典型的 MVVM 三段式但针对 MES 场景做了业务化的拆分。2.1 从解决方案到项目各层职责怎么分打开解决方案通常能看到这么几个项目客户端主程序、视图层、视图模型层、数据访问层、公共模型层外加一个服务端接口项目。视图层只放 XAML 和少量与界面强相关的代码视图模型层承载所有业务逻辑和状态数据访问层封装对 MES 服务端接口的调用。这种分法的好处在 MES 场景里特别明显车间终端可能有好几种形态——工位机、平板、大屏看板界面长得不一样但报工逻辑、工单状态流转逻辑是同一套。逻辑放在 ViewModel 里换一套 View 就能复用。我见过不少项目把业务逻辑写在 XAML 的 code-behind 里结果加一个大屏看板就得复制一遍逻辑后面改一处漏一处血泪经验。数据访问层一般会抽一个接口出来比如工单服务接口、报工服务接口实现类里用 HttpClient 调后端。这样做的直接收益是单元测试能跑——ViewModel 依赖接口而非具体实现测试时塞个假实现进去就行。MES 客户端的逻辑测试往往被忽略但工单状态机这种东西不测真的会出事。2.2 核心模块与数据模型MES 客户端的模块划分基本围绕制造现场的几个动作展开。工单模块负责拉取工单列表、展示工单详情、更新工单状态报工模块处理扫码或手动录入、校验、提交设备监控模块订阅或轮询设备状态追溯模块按批次号或序列号反查生产履历。数据模型层是这些模块的公共语言。工单模型通常包含工单号、产品编码、计划数量、已完成数量、状态枚举、计划开始结束时间。报工记录模型包含工单号、工序、操作工、设备、数量、时间戳。这些模型在客户端和服务端之间序列化传输字段命名和类型必须严格对齐否则反序列化时静默失败界面上一片空白你还以为是接口没返回。// 工单状态枚举MES 里状态流转必须显式定义避免用魔法数字 public enum WorkOrderStatus { Pending 0, // 待生产 InProgress 1, // 生产中 Paused 2, // 暂停 Completed 3, // 已完成 Closed 4 // 已关闭 } // 工单模型字段与后端接口保持一致 public class WorkOrder { public string OrderNo { get; set; } // 工单号业务主键 public string ProductCode { get; set; } // 产品编码 public int PlanQty { get; set; } // 计划数量 public int FinishedQty { get; set; } // 已完成数量 public WorkOrderStatus Status { get; set; } // 状态 public DateTime PlanStart { get; set; } // 计划开始 public DateTime PlanEnd { get; set; } // 计划结束 }上面这段模型定义看着简单但有两个参数值得说。一是状态用枚举而不是字符串好处是编译期就能发现拼写错误坏处是前后端枚举值必须约定一致我一般会在接口文档里把数值写死。二是数量字段用 int如果产线有小数计量比如按重量得换成 decimal这个在项目初期就要确认后期改类型牵涉面很大。2.3 界面布局与数据绑定骨架WPF 的界面能力是这套资源相对 WinForm 的最大优势。MES 客户端常见的布局是左侧导航、顶部工单信息条、中间主内容区、底部状态栏。用 Grid 划分行列配合 DockPanel 做区域停靠基本能覆盖大部分车间终端的分辨率。数据绑定是 WPF 的命脉。工单列表用 ListView 或 DataGridItemsSource 绑到 ViewModel 里的 ObservableCollection。这里有个关键点集合必须用 ObservableCollection 而不是 List否则后台增删数据时界面不会自动更新。我见过有人用 List 绑定然后手动调 Refresh性能差还容易出错。!-- 工单列表绑定骨架注意 VirtualizingPanel 配置 -- ListView ItemsSource{Binding WorkOrders} VirtualizingPanel.IsVirtualizingTrue VirtualizingPanel.VirtualizationModeRecycling ScrollViewer.CanContentScrollTrue ListView.View GridView GridViewColumn Header工单号 Width140 DisplayMemberBinding{Binding OrderNo}/ GridViewColumn Header产品 Width120 DisplayMemberBinding{Binding ProductCode}/ GridViewColumn Header状态 Width80 DisplayMemberBinding{Binding Status}/ /GridView /ListView.View /ListView这段 XAML 里VirtualizingPanel 的三个属性是 MES 列表性能的关键。IsVirtualizing 开启虚拟化只渲染可视区域内的行VirtualizationMode 设为 Recycling 表示复用容器而不是每次新建CanContentScroll 设为 True 让滚动按项而不是按像素虚拟化才能生效。默认配置下几千条工单一次性渲染界面卡顿是必然的。这个坑后面还会细说。3. 把客户端跑起来环境、接口对接与报工流程实现结构看清了接下来是让它真正跑起来。MES 客户端不像纯前端项目它依赖后端接口接口不通界面就是空壳。这一章按环境准备、接口对接、报工流程实现三步走每步都落到可操作的配置和代码。3.1 开发环境与依赖准备这套资源基于 .NET具体版本以项目文件里的 TargetFramework 为准常见的是 .NET 6 或 .NET Framework 4.8。前者跨平台、依赖管理用 NuGet后者在老旧车间终端上兼容性更好。先确认版本再装 SDK版本对不上项目加载就报错。依赖方面MVVM 框架通常用 CommunityToolkit.Mvvm 或 Prism前者轻量、后者功能全。HTTP 调用用 HttpClientJSON 序列化用 System.Text.Json 或 Newtonsoft.Json。数据库访问如果客户端直连可能用到 Dapper 或 EF Core但 MES 客户端一般走服务端接口不直连库。# 还原 NuGet 包并编译先确保依赖完整 dotnet restore dotnet build -c Debug # 如果项目是 .NET Framework用 msbuild msbuild MesClient.sln /p:ConfigurationDebug编译通过只是第一步。运行前要改配置文件里的服务端地址。MES 客户端的配置文件通常是 App.config 或 appsettings.json里面存接口基地址、超时时间、轮询间隔这些参数。基地址指向测试环境还是生产环境一定要确认清楚我见过有人拿生产地址调试误报了一堆工单。3.2 接口对接HttpClient 封装与超时处理MES 客户端和服务端的通信核心是一个封装好的 HttpClient。直接 new HttpClient 是常见误用会导致 socket 耗尽。正确做法是用 IHttpClientFactory 管理或者至少做成单例。// 接口调用封装统一处理超时和异常 public class MesApiClient { private readonly HttpClient _http; private readonly string _baseUrl; public MesApiClient(HttpClient http, IConfiguration config) { _http http; _baseUrl config[MesApi:BaseUrl]; // 超时设置很关键车间网络不稳定设太短频繁失败设太长界面卡死 _http.Timeout TimeSpan.FromSeconds(config.GetValueint(MesApi:TimeoutSeconds, 10)); } // 拉取工单列表带重试 public async TaskListWorkOrder GetWorkOrdersAsync(string lineCode) { var url ${_baseUrl}/api/workorder?line{lineCode}; var response await _http.GetAsync(url); response.EnsureSuccessStatusCode(); var json await response.Content.ReadAsStringAsync(); return JsonSerializer.DeserializeListWorkOrder(json); } }这段代码里超时时间从配置读默认 10 秒。车间网络抖动是常态超时设太短会频繁抛异常操作工看到的就是“网络错误”设太长UI 等待期间没反馈操作工以为死机了猛点反而触发重复提交。我的习惯是接口超时 10 秒UI 层再加一个 3 秒的加载提示让操作工知道系统在干活。重试策略要谨慎。查询类接口可以重试报工提交类接口不能盲目重试否则可能重复报工。真要重试得靠服务端的幂等设计客户端带上唯一请求 ID。3.3 报工流程从扫码到提交的完整链路报工是 MES 客户端最高频的操作链路一般是扫码枪输入工单号或序列号 → 校验工单状态 → 录入数量 → 提交 → 刷新界面。每一步都有讲究。扫码枪在系统里就是个键盘输入设备扫完自动回车。所以界面上放个 TextBox监听 KeyDown 或 TextChanged回车触发校验。校验逻辑放 ViewModel先查本地缓存的工单没有再调接口。// 报工命令用 CommunityToolkit.Mvvm 的 RelayCommand [RelayCommand] private async Task SubmitReportAsync() { // 前置校验避免无效请求打到服务端 if (string.IsNullOrWhiteSpace(CurrentOrderNo)) { ErrorMessage 请先扫描工单号; return; } if (ReportQty 0) { ErrorMessage 报工数量必须大于零; return; } IsSubmitting true; // 绑定到界面禁用提交按钮防重复点击 try { var record new ReportRecord { OrderNo CurrentOrderNo, Qty ReportQty, EquipmentCode CurrentEquipment, ReportTime DateTime.Now }; await _api.SubmitReportAsync(record); // 提交成功后刷新工单状态而不是本地改保证与服务端一致 await LoadWorkOrdersAsync(); ReportQty 0; ErrorMessage string.Empty; } catch (Exception ex) { ErrorMessage $报工失败{ex.Message}; } finally { IsSubmitting false; } }这段命令逻辑有几个参数和设计点值得展开。IsSubmitting 绑定到提交按钮的 IsEnabled提交期间按钮禁用这是防重复报工的第一道防线。提交成功后重新拉取工单列表而不是本地修改数量是为了保证客户端状态和服务端一致——本地改看着快但一旦服务端有并发报工两边数据就对不上了。ErrorMessage 绑定到界面提示区操作工能直接看到失败原因比弹 MessageBox 体验好也不阻塞操作。报工数量 ReportQty 的类型要和工单模型里的数量类型一致前面说了有小数计量就得用 decimal。设备编码 CurrentEquipment 一般从登录信息或工位配置里带出来不让操作工手输减少出错。4. 避坑与排查WPF 做 MES 客户端最容易翻车的五个地方这套资源能跑通不代表能上产线。MES 客户端在车间环境里会遇到开发机上永远复现不了的问题。下面五条是我在实际项目里踩过的按现象、原因、解决三段写照着排查能省不少时间。4.1 界面卡死UI 线程被同步调用堵住现象点击查询后界面无响应转圈都不转几秒后恢复或直接崩溃。原因在 UI 线程里同步调用了接口比如用了.Result或.Wait()等异步方法返回。WPF 的 UI 线程只有一个被阻塞期间不处理任何消息界面自然卡死。解决所有 IO 操作走 async/await从事件处理到 ViewModel 命令全链路异步。检查代码里有没有.Result、.Wait()、.GetAwaiter().GetResult()有就改掉。如果某个老接口只有同步版本用Task.Run包一层但注意别在 Task.Run 里碰 UI 元素。4.2 列表滚动卡顿虚拟化没开或容器没复用现象工单列表几百条以上滚动时明显掉帧鼠标滚轮一顿一顿。原因ListView 或 DataGrid 默认虚拟化在某些布局下会失效比如把 ListView 放在 ScrollViewer 里外层滚动会撑开所有项虚拟化形同虚设。或者 VirtualizationMode 没设成 Recycling每次滚动都新建容器。解决确认 ListView 没有被外层 ScrollViewer 包裹设置VirtualizingPanel.IsVirtualizingTrue和VirtualizationModeRecycling。如果列表项高度不固定虚拟化效果会打折尽量让行高固定。4.3 数据不刷新集合类型用错或没通知现象后台数据变了界面纹丝不动手动刷新才更新。原因绑定的集合用了 List 而不是 ObservableCollection或者 ViewModel 属性没有实现 INotifyPropertyChanged界面收不到变更通知。解决集合统一用 ObservableCollection。单个属性变更靠 INotifyPropertyChanged用 CommunityToolkit.Mvvm 的 ObservableObject 基类和[ObservableProperty]特性省得手写。注意[ObservableProperty]生成的属性名首字母大写绑定时别写错。4.4 报工重复提交防抖没做或按钮没禁用现象操作工点一次提交服务端收到两三条相同记录。原因提交按钮没在请求期间禁用操作工看没反应就连点或者扫码枪回车触发多次或者网络慢导致超时重试而接口没有幂等。解决提交期间禁用按钮IsSubmitting 绑定 IsEnabled扫码输入加防抖比如 300 毫秒内不重复触发提交接口带唯一请求 ID 做幂等。三管齐下基本能杜绝。4.5 配置写死环境切换要重新编译现象测试环境跑通的客户端拿到生产环境连不上改地址还得重新编译发版。原因服务端地址、超时时间这些参数硬编码在代码里没抽到配置文件。解决所有环境相关参数放 appsettings.json 或 App.config用 IConfiguration 读取。发布时不同环境带不同配置文件或者用环境变量覆盖。MES 客户端经常要在多个车间部署配置化是基本要求。5. 进阶技巧用后台轮询和状态缓存把实时性做稳基础功能跑通后MES 客户端的真正考验是实时性。车间看板要求工单状态、设备状态近乎实时更新但频繁轮询接口会给服务端压力也浪费车间终端的资源。这一章讲两个我常用的技巧带退避的后台轮询以及本地状态缓存。5.1 后台轮询定时器选型与退避策略WPF 里做定时轮询别用 System.Timers.Timer 直接更新 UI它回调在非 UI 线程。用 DispatcherTimer 简单但精度一般或者用 PeriodicTimer 配合 async 循环更现代。// 带退避的后台轮询网络异常时拉长间隔避免雪崩 private async Task PollWorkOrdersAsync(CancellationToken token) { var interval TimeSpan.FromSeconds(5); // 正常间隔 var maxInterval TimeSpan.FromSeconds(60); // 最大退避间隔 while (!token.IsCancellationRequested) { try { var orders await _api.GetWorkOrdersAsync(CurrentLine); // 回到 UI 线程更新集合 Application.Current.Dispatcher.Invoke(() { WorkOrders.Clear(); foreach (var o in orders) WorkOrders.Add(o); }); interval TimeSpan.FromSeconds(5); // 成功则恢复间隔 } catch { // 失败则退避间隔翻倍直到上限 interval TimeSpan.FromSeconds( Math.Min(interval.TotalSeconds * 2, maxInterval.TotalSeconds)); } await Task.Delay(interval, token); } }这段轮询逻辑的关键参数是正常间隔和最大退避间隔。正常 5 秒一次对多数车间看板够用网络异常时翻倍退避到 60 秒避免服务端已经扛不住还被客户端猛打。更新集合时用 Dispatcher.Invoke 切回 UI 线程这是 WPF 跨线程更新界面的硬性要求漏了会抛 InvalidOperationException。轮询的替代方案是服务端推送比如 SignalR。但车间网络环境复杂长连接维护成本高很多项目最后还是回到轮询。轮询不是落后是权衡后的稳妥选择。5.2 本地状态缓存减少无效请求工单列表里大部分工单状态短时间内不会变。每次轮询全量拉取数据量大时浪费带宽。可以在客户端做一层缓存只请求有变化的工单。常见做法是记录上次拉取的时间戳接口支持增量查询只返回该时间之后有变更的工单。客户端把增量结果合并到本地集合。这样轮询的数据量大幅下降界面更新也更快。// 增量合并只更新有变化的工单 private void MergeWorkOrders(ListWorkOrder changed) { foreach (var item in changed) { var existing WorkOrders.FirstOrDefault(o o.OrderNo item.OrderNo); if (existing null) { WorkOrders.Add(item); // 新工单 } else { // 已有工单更新字段 existing.Status item.Status; existing.FinishedQty item.FinishedQty; } } }合并逻辑里工单号是业务主键用它匹配。已有工单只更新变化字段不整体替换避免界面闪烁。这里有个细节ObservableCollection 里修改元素属性界面能收到通知的前提是元素本身实现了 INotifyPropertyChanged。如果 WorkOrder 是个普通类改了 Status 界面不会更新。所以模型类要么实现通知接口要么整体替换元素。我一般让模型实现通知改字段更轻量。5.3 验证实时性用日志和计时器量化实时性做没做好不能靠感觉。我会在轮询和界面更新处打日志记录每次拉取耗时、数据条数、界面更新耗时。跑一段时间看日志如果拉取耗时经常超过轮询间隔说明间隔设太短或接口太慢得调整。// 简单计时定位性能瓶颈 var sw Stopwatch.StartNew(); var orders await _api.GetWorkOrdersAsync(CurrentLine); sw.Stop(); _logger.LogInformation(拉取工单 {Count} 条耗时 {Elapsed}ms, orders.Count, sw.ElapsedMilliseconds);日志里如果看到拉取耗时稳定在几十毫秒轮询间隔 5 秒绰绰有余如果经常几百毫秒甚至超时要么优化接口要么拉长间隔。量化之后调整参数心里有底不用猜。从那以后我每次接手 MES 客户端都先把轮询间隔、超时时间、虚拟化配置这三项过一遍再谈功能开发。这三项定不好后面功能做得再花哨操作工一句“卡”就全盘否定。希望帮到你。本文还有配套的精品资源点击获取