基于MFC MDI的仿SecureCRT终端模拟器架构设计咨询

核心原则：复用优先，职责分离 #

围绕减少冗余代码和模块解耦设计，避免多文档模板带来的重复逻辑，让各层职责清晰。

1. 是否为每个协议创建独立文档模板？ #

不需要。多文档模板会导致窗口管理、会话配置等大量逻辑重复，违背复用原则。建议采用单一文档模板，通过协议工厂类实例化不同协议的处理对象，文档类作为容器关联对应协议实例即可。

2. 是否将所有逻辑处理放在Document类，仅让View类负责显示？ #

这是更合理的职责划分：

• Document类：作为会话核心容器，负责：
  • 管理协议实例（持有抽象协议类指针，根据会话类型实例化Telnet/SSH等子类）
  • 处理协议连接、断开、数据收发的调度（具体协议逻辑抽离到独立协议类）
  • 会话配置、日志的持久化
  • 转发View传来的用户输入给协议类，再把协议类返回的服务器数据传给View
• View类：专注UI层，负责：
  • 终端界面渲染（字符显示、光标、颜色、滚动等）
  • 捕获用户键盘/鼠标输入，转发给Document处理
  • 接收Document推送的服务器输出，更新界面

3. 是否让View类承担连接、读取用户输入及显示服务器输出的全部工作？ #

不建议。这种模式会让View类职责过载，既管UI又管协议逻辑，后续扩展SSH或其他协议时，必须修改View类，违反开闭原则。而且MFC中View依赖Document，把协议逻辑放在View里会导致会话数据的复用和管理变得混乱。

4. 是否需要为每个协议设置独立View？ #

不需要。终端View的核心功能是字符渲染和输入捕获，与协议类型无关——无论Telnet还是SSH，最终都是将字节流转换为可显示的文本。协议差异完全由底层协议类处理，View只需处理统一的文本输出和输入事件即可。

落地步骤参考 #

• 抽象协议基类：定义IProtocol接口，包含Connect、Disconnect、SendData、RecvData等纯虚函数，将已完成的命令行Telnet逻辑移植到CTelnetProtocol子类，后续SSH等协议只需实现该接口。
• Document类：持有IProtocol*指针，根据用户选择的会话类型创建对应协议实例，处理View与协议类的交互。
• View类：继承自自定义终端控件（或增强版CEdit），仅处理UI相关逻辑，通过Document完成数据交互。
• 会话管理：主框架维护会话列表，用户新建会话时选择协议类型，Document根据选择实例化对应协议对象。

内容的提问来源于stack exchange，提问作者NiemandDenDuKennst