Named Pipes vs COM Interop | TapProject V3.0 MVP 架构评估
| 评估维度 | Named Pipes 推荐 | COM Interop 备选 |
|---|---|---|
| 部署复杂度 | 低 — 只需管道名约定，无需注册组件 | 高 — 需 RegAsm / regsvr32 注册 COM 组件，配置 DCOM 权限 |
| 强类型体验 | 弱 — 需手动序列化/反序列化（JSON / Protobuf） | 强 — .NET 自动生成 RCW，接口调用如同本地对象 |
| 跨机器扩展 | 天然支持 — 可平滑切换到 TCP / gRPC | 需 DCOM，防火墙与网络配置复杂 |
| 权限要求 | 低 — 同机管道访问即可，无需特殊权限 | 需 DCOM 权限配置，企业安全策略常受限 |
| 未来 .NET 兼容性 | 完全兼容 .NET 6 / 7 / 8+ | Microsoft 已逐步弱化 COM 投入，.NET Core 支持有限 |
| 性能 | JSON 有序列化开销，但管道本身高效；可换 Protobuf 优化 | 二进制 marshaling 开销小，但有额外 proxy/stub 层 |
| 调试 / 运维 | 管道状态易排查，日志直观 | COM 注册问题、权限问题是常见故障源 |
| 与现有代码集成 | 需编写连接管理、帧解析逻辑 | 接口定义后客户端代码简洁，类似本地调用 |
Broker 与客户端永远在同一台机器，团队熟悉 COM 部署，希望获得透明代理般的调用体验。
项目中已有成熟的 COM 接口定义或第三方 COM 组件，可直接复用。
无需注册 COM 组件，管道名约定即可通信，运维成本极低。
未来若 Broker 需部署到远程机器，Named Pipes 可平滑切换到 TCP/gRPC，COM Interop 则需大幅改造。
DCOM 权限在企业安全策略下经常受限，Named Pipes 无此问题。
项目虽当前为 .NET Framework 4.7.2，但 COM Interop 在 .NET 5+ 上支持逐步弱化，Named Pipes 无此顾虑。
保持 Named Pipes 方案。
对于 Broker 跨进程通信场景，Named Pipes 在部署简易性、未来扩展性和平台兼容性上均优于 COM Interop。
MemoryPack 或 Protobuf-net 替代，同时保留 Named Pipes 的架构优势。在已完成的 MVP 实施中，跨进程通信分为两层：
| 层级 | 机制 | 状态 |
|---|---|---|
| 仲裁层（arb.db） | SQLite WAL 模式 + BEGIN IMMEDIATE 事务 — 进程间仲裁完全依赖数据库事务，无需 IPC | ✅ 已实现 |
| Broker 命令通道 | Named Pipes 帧协议（4B 长度 + JSON）— 用于客户端向 DeviceBroker.exe 下发设备操作 | ⏳ 计划中（P2+） |
注：当前 MVP 仅实现了 Local 模式（进程内直驱）和 DbLeaseStore（SQLite 仲裁）。Broker 模式的命令通道属于后续迭代范围，此时选择 Named Pipes 作为 IPC 方案仍有充分调整空间。