简介：面向 Delphi 12.3 开发者的 kbmMW Enterprise Edition 4.93 适配安装包，包含完整组件源码与预编译单元，适合需要在企业级中间件、远程调用与分布式多层架构中快速集成 kbmMW 的开发者。压缩包共 2000 个文件，约 30.67MB，涵盖 pas 源码、hpp 头文件与 dcu 编译单元等关键内容，辅以 bmp 图标、txt 说明以及 dpk/dproj 工程文件，便于按需安装、查阅和二次编译。其中 hpp/dcu 用于直接链接部署，pas 可深入研读实现，图标与文档则辅助界面识别和环境配置。组件库覆盖查询池化、负载均衡、客户端传输插件等模块，核心类设计清晰，能帮助开发者理解中间件底层机制与服务调用方式。目前已有 69 人学习下载，适合具备一定 Delphi 基础、希望扩展企业级服务能力的开发者收藏使用。
1. kbmMW 是什么——为什么企业级 Delphi 项目需要它
先给结论：kbmMW Enterprise Edition 4.93 for D12，就是一套让 Delphi 12.3 客户端和服务端共用同一套业务模型的中间件框架。它解决的不是“控件好不好用”的问题，而是当项目需要接入数据库、暴露远程接口、做权限校验时，能不能用同一种语言、同一种序列化方式，把后端逻辑统一管理起来。
很多从 DataSnap 或手工 socket 迁过来的团队，都有同一个感受：通信层代码写了太多遍。无论是 TCP、HTTP 还是命名管道，协议格式、心跳、序列化和异常传递，占据了最没有业务价值的那部分工作量。kbmMW 把传输层抽象成可替换的接口，开发时只关心定义服务类和客户端调用，部署方式从内网 TCP 改成公网 HTTPS，只需要调整传输配置，服务代码几乎不用动。对五年以上 Delphi 工程师来说，这个抽象方式带来的架构收益，比省几行代码重要得多。
接下来的内容按照落地路径展开：先解决安装和编译，再把传输、服务和认证三层结构讲清，然后跑通一个最小客户端-服务器示例，最后补充 ORM 映射和异常传递的进阶处理。适合正在评估迁移方案的技术负责人，也适合刚拿到 4.93 版本、还没跑通第一个调用的开发者。
2. 在 Delphi 12.3 中安装 kbmMW Enterprise Edition 4.93
2.1 7z 包解压后的目录与取舍
kbmMW 发布包用 7z 压缩，解压后面对多个子目录。4.93 的典型结构包含Source、Packages、Examples和Docs四大块。Source里是核心运行库单元，编译时会根据条件分支引入不同模块；Packages按 Delphi 版本区分 dpk 工程文件，D12 指的是 Delphi 12 那一套；Examples里有大量按功能划分的演示工程，建议完整保留；Docs下的 HTML 文档在排查问题时比直接翻源码更快。
目录规划有个容易忽略的点：安装路径不要使用中文或带空格。Delphi 12.3 的库搜索机制在无空格路径下最稳，建议固定在例如D:\ThirdParty\kbmMW-4.93这种位置。移动包路径后 IDE 会留下过期的缓存引用，等到编译报错才意识到，排查成本反而更高。
2.2 Library 路径配置与编译顺序
配置步骤比较固定：打开 Tools 菜单下的 Options，在 Environment Variables 区域找到 Delphi Options，进入 Library 页，把Source目录加入 Library path。留意 32-bit 和 64-bit 平台搜索路径分别需要设置，切换目标平台时 IDE 不会自动复制原有路径，这是一个非常典型的“单独一个平台能编、换位宽就报找不到单元”的原因。
安装前确认 Indy 组件包已存在，因为 TCP 传输默认依赖 Indy。Indy 在 Delphi 12.3 中作为标准库提供，如果你之前为了精简环境手动移除过，需要先恢复。另一个常见报错是：
E2003 Undeclared identifier: 'TkbmMWCustomService'这说明 kbmMW 运行库还没有被编译。正确顺序是先编译运行库包，再打开自己的项目。在Packages目录下找到对应的 dpk 文件（如kbmMW_Run.dpk），右键选择 Build，等待编译完成。跳过这一步直接编译示例工程，链接阶段很容易出现重复定义或找不到实现单元的错误。
Tools → Options → Delphi Options → Library注意右上角平台切换，分别把Source目录加入 32-bit Windows 和 64-bit Windows 的搜索路径。这个配置和 Delphi 12.3 的 Platform 设置联动，只配一次只对当前平台生效。
之后新建一个空白 VCL 应用，在uses中写入kbmMWServer，能够编译即为成功。再加一行代码验证运行库加载：
procedure TForm1.FormCreate(Sender: TObject); var LServer: TkbmMWServer; begin LServer := TkbmMWServer.Create(nil); LServer.Free; end;TkbmMWServer是服务端核心类，能创建成功说明运行库中的类注册和单元引用没有问题。这里不需要启动服务，只是验证运行库能正常工作，避免后续把链接错误与业务代码报错混淆。
2.3 包依赖与授权文件的边界
kbmMW 4.93 的 Enterprise Edition 在功能上不会因缺少授权文件而停摆，但商用环境必须在代码中加载合法许可信息。这和开放的评估版不同，Enterprise 编译后运行时，程序会主动查找许可证，找不到时弹出提示并拒绝某些企业级功能。不要在项目里用硬编码路径写死许可证地址，建议通过环境变量或配置文件指定许可文件路径，便于不同环境部署。
KBMMW_LICENSE_FILE=C:\ProgramData\kbmMW\license.dat把环境变量配置交给部署脚本，程序启动时读取GetEnvironmentVariable，代码里不暴露任何路径信息，这样既方便不同机器的部署，也避免了授权文件路径写死导致换服务器后无法启动的问题。
3. kbmMW 的传输、服务和认证三层架构
3.1 为什么抓 kbmMW 必须从这三层入手
kbmMW 的架构设计始终围绕三层展开：传输层负责字节流收发，服务层负责业务方法暴露，认证层负责调用方身份校验。初学者最容易犯的错误是直接套用传统客户端-服务器思维，把业务逻辑写在 Form 事件里，结果发现远程调用根本不触发。原因在于 kbmMW 中服务必须显式注册，不注册的服务方法不可能被客户端调用。
传输层负责数据如何流动，服务层负责数据如何表达，认证层负责调用是否合法。三个层次彼此独立，职责明确。配置 TCP 传输时，指定端口、编码方式和最大包长；定义服务时，只写业务方法；认证规则挂在 Server 实例上，与具体传输无关。这种解耦方式在项目规模变大后优势明显：更换传输协议无法影响服务定义，调整认证策略也不会动到已有接口。
3.2 声明一个可远程调用的 kbmMW 服务
创建一个单元，定义服务类如下：
unit uMyFirstService; interface uses kbmMWCustomService; type TMyFirstService = class(TkbmMWCustomService) published function Echo(const AText: string): string; end; implementation function TMyFirstService.Echo(const AText: string): string; begin Result := 'kbmMW 服务端返回：' + AText; end; end.注意published而不是public。kbmMW 的远程调用机制依赖 Delphi 的 RTTI，只有published区中的方法才会被框架识别为可远程调用的接口。方法名Echo将作为远程接口名的一部分，客户端调用时用字符串定位。
这个方法不依赖任何窗体或全局变量，因此单元内不引用 Forms。对于维护老项目的团队，这种设计需要适应一下，但好处是服务逻辑可以脱离 UI 做单元测试。
3.3 注册服务与认证器绑定
服务类定义后，需要注册到 Server 实例上。在服务端窗体创建时完成三件事：创建传输层、创建认证器、注册服务。
procedure TfrmServer.FormCreate(Sender: TObject); var LTransport: TkbmMWTCPIPIndyTransport; LAuthHandler: TkbmMWAuthAll; begin // 第一步：创建 TCP 传输，指定监听端口 LTransport := TkbmMWTCPIPIndyTransport.Create(nil); LTransport.Port := 8088; // 第二步：创建认证器，按用户名密码放行 LAuthHandler := TkbmMWAuthAll.Init( function(const AUser, APassword, ASession: string): Boolean begin Result := (AUser = 'admin') and (APassword = '123456'); end ); // 第三步：创建服务器，绑定传输和认证 FServer := TkbmMWServer.Create(nil); FServer.Transport := LTransport; FServer.AuthHandler := LAuthHandler; FServer.RegisterService(TMyFirstService); FServer.Start; end;TkbmMWTCPIPIndyTransport是 4.93 中最常用的 TCP 传输实现。TkbmMWAuthAll表示对所有调用统一执行一次回调判断，回调返回 True 则调用方获得授权。RegisterService传入服务类类型而不是实例，这是因为 kbmMW 采用按需实例化策略，每个会话或请求可能创建不同实例，避免多线程下的数据竞争。
参数说明：Port定义监听端口；AuthHandler指定认证器；会话 IDASession在回调触发时为空，因为这一步尚未建立会话；用户名和密码明文出现在回调里，仅适合内网开发环境，生产环境建议改造为数据库或令牌校验。
4. 在 4.93 中跑通客户端-服务器通信
4.1 搭建服务端启动的最小工程
承接上一章，把服务端封装成一个独立工程。使用 VCL 应用，Form 上放一个TButton用于启动和停止，再放一个TMemo显示日志。完整代码如下：
procedure TfrmServer.btnStartClick(Sender: TObject); var LTransport: TkbmMWTCPIPIndyTransport; begin if Assigned(FServer) then Exit; LTransport := TkbmMWTCPIPIndyTransport.Create(nil); LTransport.Port := 8088; LTransport.MaxPacketSize := 16 * 1024 * 1024; // 16MB FServer := TkbmMWServer.Create(nil); FServer.Transport := LTransport; FServer.RegisterService(TMyFirstService); FServer.Start; Memo1.Lines.Add('服务已启动，监听端口 8088'); end;MaxPacketSize决定 TCP 包的最大字节数，默认值通常较小，传输较大数据集时容易触发异常。这里设置 16MB，可以根据业务峰值调整。注意TkbmMWServer在Start调用前，传输对象必须存在且端口未被占用。
停止服务时调用FServer.Stop，然后依次释放服务器和传输对象。顺序不能反过来，先释放传输再释放服务器，会导致服务器内部仍然引用已释放的传输对象，触发访问冲突。
btnStartClick → 创建传输 → 创建服务器 → 注册服务 → Start btnStopClick → Stop → Free Server → Free Transport4.2 客户端通过传输定位远程服务
客户端代码相对直观，创建传输、创建客户端、连接、调用方法。调用远程方法在 kbmMW 中有两种方式：基于字符串的Invoke和基于接口的强类型调用。先用字符串方式建立初步理解。
procedure TfrmClient.btnCallClick(Sender: TObject); var LTransport: TkbmMWTCPIPIndyTransport; LClient: TkbmMWClient; LResult: string; begin LTransport := TkbmMWTCPIPIndyTransport.Create(nil); LTransport.Host := '127.0.0.1'; LTransport.Port := 8088; LClient := TkbmMWClient.Create(nil); try LClient.Transport := LTransport; LClient.Connected := True; LResult := LClient.Invoke( 'TMyFirstService.Echo', ['你好，kbmMW'] // 参数数组 ); Memo1.Lines.Add('调用结果：' + LResult); finally LClient.Free; LTransport.Free; end; end;Invoke的参数形式是方法全名前缀加方法名，大小写敏感。第二个参数是array of Variant，按顺序对应服务端方法的形参。返回值也是Variant，这里依赖 kbmMW 的流序列化机制把它还原为字符串。如果调用的方法不存在，客户端会抛出EkbmMWRemoteException，异常信息中包含服务端具体错误内容。
连接成功后Connected := True会建立一个持久会话，每次Invoke都复用同一 TCP 连接，避免频繁握手带来的开销。若要强制断开，设置Connected := False。
4.3 传输超时和大数据块的处理
局域网环境调用通常毫秒级返回，但公网场景下需要处理超时。传输对象上提供Timeout属性，单位是毫秒，默认值偏小，建议设置为 30000。
LTransport.Timeout := 30000; // 30 秒连接超时 LTransport.MaxPacketSize := 64 * 1024 * 1024; // 64MB，用于大文件传输超过MaxPacketSize的调用，kbmMW 会先尝试分块，但分块后无法保证一次Invoke调用，需要调用方自行处理。实际项目中，超过 8MB 的数据不要直接塞进Invoke的参数数组里，改为先传输到临时文件，再通过流式接口上传，这样能避开很多 TCP 栈层面的限制。
对于文件上传类场景，推荐使用独立传输通道。kbmMW 支持在同一端口上创建多条虚拟通道，但实现的复杂度较高，如果时间允许，更稳妥的做法是单独开一个端口做高吞吐传输，和基本方法的短报文通道分开管理。这样既能把超时和重传策略分开设置，也能避免大包阻塞其他远程方法的调用。
5. 进阶：ORM 对象映射与异常传递的落地细节
5.1 用 kbmMW 直接操作数据库返回对象
kbmMW 不只是远程调用框架，它还包含一套对象持久化能力，核心是TkbmMWSQLDBResolver配合TkbmMWObjectStore。理念是直接定义对象模型，由框架负责对象的增删改查，开发者无需手写 SQL。
type TCustomer = class private FId: Integer; FName: string; FBalance: Currency; published property Id: Integer read FId write FId; property Name: string read FName write FName; property Balance: Currency read FBalance write FBalance; end;服务端方法中声明返回对象数组：
function TCustomerService.GetCustomers: TkbmMWObjectList; begin Result := TkbmMWObjectList.Create; // 在真实项目中，这里通过 Resolver 查询数据表并填充对象 end;对象属性同样需要放在published区，否则 Resolver 无法识别哪些字段需要映射。属性名和数据库字段名不一致时，需要在配置 Resolver 的数据映射表中处理一对一映射，否则全部自动同名匹配。
查询中文乱码的问题在绑定数据库时经常出现。4.93 中对象到字段的类型转换遵循其内部元数据定义，推荐数据库连接设置字符集为 UTF-8，同时确保对象属性类型是string而非AnsiString。这一条对应前面反复出现的“Delphi sqlite 亂碼”类痛点，kbmMW 本身不消费本地 SQLite 连接，但通过它持久化的对象经过序列化后会经过传输线路，字符集不统一时，问题会被放大到客户端才显现，排查成本极高。
5.2 异常如何在客户端保持结构
服务端抛出的异常默认会被 kbmMW 捕获并序列化，客户端接收后抛出EkbmMWRemoteException。调试时有个痛点：默认的异常信息只包含消息文本，堆栈完全缺失。在服务端启用异常堆栈追踪，会在客户端拿到更完整的上下文。
FServer.OnError := procedure(Sender: TObject; E: Exception; var AHandled: Boolean) begin AHandled := False; // 让服务端继续按默认机制传递异常 end;不建议完全吞掉异常，因为客户端拿不到任何信息时，问题会被描述成“远程调用失败”，定位起来更耗时。另一个建议是，不要把所有异常都包成 EKbmMWRemoteException 重新抛出，这样会丢失原始异常类型。让自定义异常类继承自EkbmMWCustomException，框架会保留异常类名，客户端可以根据类名做分支处理。
5.3 验证部署的顺向检查清单
收尾阶段提供一套验证步骤，按顺序执行，能覆盖绝大多数“代码在 IDE 里正常、脱离 IDE 出错”的情况。
netstat -ano | findstr :8088执行后若看不到监听，先检查服务端进程是否真的启动，再用 telnet 模拟一次连接。端口能通但调用失败，把客户端设为本机回环地址验证，确认问题发生在传输还是服务内部。最后检查许可文件，确认环境变量KBMMW_LICENSE_FILE指向的文件存在且未过期。这套顺序可以避免把运行环境问题当成代码缺陷来排查。
本文还有配套的精品资源，点击获取
