前言

由于近期我做了好几个客户的接入工厂Mes系统的需求。但是每个客户的Mes都有不同程度的定制需求，原有的代码复用难度其实很大。所以打算将整个接入Mes系统的框架单独拿出来作为一个项目使用，同时因为不同的设备接入同一个Mes系统，所以代码的迁移规范同样非常重要。

2025.5.2修改：这个是一个长期更新的项目，我发现现在代码量在上升。此博文仅为介绍这个项目，原本的本博文的代码全部被删除，需要代码的可以移步我个人的Github仓库，同时我在CSDN的Git仓库也做了镜像，不过我一般会优先更新GitHub仓库的内容。现在因为工作原因有点忙，Github仓库的代码可能不会更新太勤快。
GitHub：https://github.com/2825077535/StandardMesFramework.git（直接粘贴即可克隆）
CSDNGit：https://gitcode.com/m0_51559565/StandardMesFramework.git（上不了Github可以克隆这里的）

1.需求分析

这部分的需求分析，主要来自于我在接入不同客户Mes系统时发现的一些问题和解决方案，同时也了解过工厂Mes系统供应商的朋友们。列举了一些比较实际的功能（主要是代码方面的）。

1. 需要有同一个的接入方式，方便接入不同客户的Mes系统。
2. 需要有全局的参数列表。
3. 只允许存在一个Mes系统的入口。
4. 保证数据统一性，在多线程访问，设备不同轨道运行时，数据需要做区分。
5. 尽可能的减少后续的代码修改。
6. UI上，不同的客户的选项卡要做区分，但是只显示一个选项卡。
7. 所有关于Mes的操作需要独立于设备内容，方便在不同设备软件上迁移，设备软件只做传入数据的功能。
8. 需要考虑由Mes控制设备的功能

2.设计项目内容

1. 首先会有一个MesApp的入口，用来访问整个Mes系统，但是这个入口只能有一个，所有MesApp应当使用单例模式。
2. 不同的客户需要继承于同一个接口，根据客户的名称信息去访问指定的客户类，所以MesApp应当具有工厂模式，通过工厂生产客户类。
3. 根据全局参数列表，需要一个可通过MesApp访问的全局静态类Const，和枚举类
4. 保证数据做好区分，但是又保证数据统一性，所以Mes需要全部公用一个数据类对象，并且可以在外部写入参数，并作为类对象进行传参
5. UI上面仍然使用MVVM框架去实现，同时使用Visibility的binding的形式来控制在选项卡中显示UI（根据实际情况可以选择公用选项卡或者，多选项卡的形式）
6. 考虑数据的通用性，所以数据应到以类对象的形式存在（类型为String的Name，类型为Object的Value）
7. 需要独立的数据存储部分，通讯方式需要独立，
8. 在MesApp中需要由一个队列跟软件的框架进行通讯，用来控制软件执行某些内容

3.代码内容

3.1MesApp入口

首先MesApp是整个项目的入口，除了数据结构类以外，全部数据都应该从MesApp的端口中进入。所以MesApp有一个单例的入口。其中包含，config配置文件，const在软件运行时的不用存储的变量，IMesSend接口与Mes交互的主要代码，Enum需要使用的枚举值。同时在进入Mes前，需要根据不同的客户去选择我们需要的使用的Mes内容，所以有一个创建mes的函数。同时还有保存配置和获取配置的部分

3.2IMesSend接口

IMesSend接口是项目主要的内容，在创建Mes时，会使用工厂模式，通过IMesSend接口去生产指定的客户类，客户类通常包含我们自有设备通常需要上传的函数方法。同时包含一个动态接口，因为在某些客户需要定制一些独特的功能，但是大部分客户都是没有的，可以使用这个Task Dynamic(MesDynamic dynamic);的接口。

3.3通讯类

通讯类所需要做的内容并不是很多，需要有创建通讯的步骤，发送数据，监听端口，关闭通讯就可以了。

3.7，框架整体解析

如下图所示：整体框架包含7个部分。
1：Client，客户类。由于每个客户都有独特的定制需求，所以所有的客户定制的内容都存放再Client中，便于管理
2：CommModel，通讯类。存放每种不同通讯方式的方法，通常最常使用的是Http和Socket，如果有另外特殊的通讯模式还可以单独编写。
3：Config，配置文件类。推荐使用可读的Json格式。一开始编写Mes时候就有一个客户是在登陆工程师级别账户时要求Mes通讯同意，但是由于客户Mes在升级无法通讯，所有软件登陆不了工程师级别，无法关闭Mes，造成需要软件重新配置参数。所以需要在特殊情况下，可以手动配置Mes参数。不同的客户Mes配置也是单独做出区分即可，在打开软件时将json反序列化到MesApp下面的Config字段中，即可全局使用。
4.Const，参数类。MesConst，用于存放软件中需要使用但是不需要保存的配置参数。MesData，用于存放自定义的数据结构。MesDynamic，一个动态数据结构类，这个类存在的意义在于，所有的接口传入传出都可以使用这个类对象，所有的数据都可以在这个类中建立新的字段，这个是考虑在，某些定制的客户中，一些框架满足不了的需求，可以在这里做新增内容。MesEnum，枚举类，用来存入Mes的枚举，例如客户枚举，设备状态代码等。其中包含，访问Description参数的方法。
5.Log，日志类，将mes的日志与原有的软件日志做区分防止单日的日志过多。
6.Model，方法类，这里存放着Json和Xml的序列化和反序列化的方法类，就暂时来说，客户的序列化都是Json或者Xml的形式。
7.接口类和MesApp的单例入口

3.8，举例部分方法使用方式

报警和取消报警的调用

3.9，UI部分

由于我使用的WPF框架，对winform，QT的框架并不是很熟悉，所以这里只使用WPF框架的内容作为参考
1.选择厂商的UI。WPF的UI其实编写很简单，核心在于Visibility=“{Binding }”>的使用，例如，在选择厂商前，需要将选择厂商的选项卡显示，厂商选项卡隐藏，那么将选择厂商选项卡的binding设置为显示，其他全部厂商选项卡设置为隐藏。同理选择完厂商后就将指定厂商的选项卡显示即可。
2.参数的Binding，如果是需要保存在配置文件中的，可以使用Binding的Value指向Config的类即可。
3.由于UI部分难度不高，并且大家UI都是不一样的，所以这里仅说一下我是怎么使用UI的

4.总结

整个标准Mes框架并不是很难。难点只有一个是如果将数据灵活应用，在常见编写Mes时，由于每个客户的数据结构都是不一样的，每个客户都需要单独开多个数据结构类去序列化和反序列化，当然这个并没有错，只是这样子会导致代码冗杂量非常大，而且维护难度大，代码命名混乱的问题。所以标准框架主要还是提供一个如何解决数据灵活性的思路而已。除去这个以外，其他内容并不是很难，剩下的就是如何规范后续客户的扩展性，和如何高效的实现解耦和代码迁移。

最后，如果有什么想法可以持续交流。有时间的话，这个标准接口框架还会随着我接入Mes的次数而优化。

寄语

克隆代码库时，不妨在GitHub点个星星。