要对某种协议进行编解码操作，就必须知道协议的基本定义，首先我们来看一下 CJ/T188 的数据帧定义(协议定义)，了解请求数据与响应数据的基本结构。
请求帧：
| 字节 | 值 | 描述 |
|---|---|---|
| 0 | 0x68 | 数据帧开始标识。 |
| 1 | T | 表计类型代码，详细信息请参考 表计类型表 。 |
| 2-8 | A0-A6 | 表计地址，水表设备的具体地址，这里是 BCD 形式。 |
| 9 | CTR_01 | 协议控制码，例如 0x1 就是读表数据。 |
| 10 | 0x3 | 数据域长度。 |
| 11-12 | 0x1F,0x90 | 数据标识 DI0-DI1。 |
| 13 | 0x00 | 序列号，一般为 0x00，序列号也被作为整个数据域的长度。 |
| 14 | CS | 表示校验和数据，即 0-13 位置的所有字节的累加和。 |
| 15 | 0x16 | 数据帧的结束标识。 |
例如有以下请求帧数据(读取水表数据)：
在使用 DevExpress 的 GridControl 为其实现 Checkbox 列，发现如果勾选了三行的数据，在遍历 GridControl 绑定的数据源时 Checkbox 列的数据仅有 2 行被更新。
使用 Google 搜索了半天，在 DevExpress 的 Support 上找到了答案，似乎是需要手动调用 GridControl 关联 View 的 PostEditor() 方法。
最近在进行硬件上位机开发的时候，经常会遇到将 16 进制字符串转换为 byte[] 的情况，除了这种需求以外，还需要判定一个字符串是否是有效的 16 进制数据。
ABP vNext 框架在使用依赖注入服务的时候，是直接使用的微软提供的 Microsoft.Extensions.DependencyInjection 包。这里与原来的 ABP 框架就不一样了，原来的 ABP 框架还需要抽象出来一个 IIocManager 用来管理整个 IoC 容器，现在则直接操作 IServiceCollection 与 IServiceProvider 进行组件的注册/解析。
这里需要注意的是，虽然现在的依赖注入服务是使用微软官方那一套库进行操作，但是 ABP vNext 还是为我们提供了组件自动注册、拦截器这些基础功能。
本篇文章主要分析 Abp vNext 当中的模块系统，从类型构造层面上来看，Abp vNext 当中不再只是单纯的通过 AbpModuleManager 来管理其他的模块，它现在则是 IModuleManager 和 IModuleLoader 来协同工作，其他的代码逻辑并无太大变化。
Abp vNext 规定每个模块必须继承自 IAbpModule 接口，这样 vNext 系统在启动的时候才会扫描到相应的模块。与原来 Abp 框架一样，每个模块可以通过 DependsOnAttribute 特性来确定依赖关系，算法还是使用拓扑排序算法，来根据依赖性确定模块的加载顺序。(从最顶层的模块，依次加载，直到启动模块。)
