深入解析MFC文档/视图架构：从核心原理到BCG界面集成实践

1. 项目概述：为什么我们需要深入理解MFC的文档/视图架构？

如果你在Windows平台上用C++和MFC（Microsoft Foundation Classes）做过桌面应用开发，尤其是那些需要处理复杂数据、支持多视图显示或者有文件操作需求的应用，那么“文档/视图体系结构”这个概念你一定绕不开。它几乎是MFC应用程序框架的灵魂，也是很多新手从写简单对话框程序转向开发复杂单文档（SDI）或多文档（MDI）应用时，遇到的第一个“认知门槛”。很多人觉得MFC老旧、过时，但恰恰是这套诞生于90年代初的架构，其设计思想——数据与显示的分离——至今仍在许多GUI框架中有所体现。理解它，不仅是理解MFC，更是理解一种经典的桌面应用设计模式。

简单来说，文档/视图架构的核心就是把程序的数据管理（文档）和数据显示与用户交互（视图）分离开。文档对象（CDocument派生类）负责数据的加载、保存和内部维护；视图对象（CView派生类）则负责把文档里的数据画到屏幕上，并处理用户的鼠标键盘操作。一个文档可以对应多个视图，比如同一份数据，你可以同时用表格视图和图表视图来展示，任何一处的数据修改都能实时同步到所有视图上。而CFrameWnd（框架窗口）和CDocTemplate（文档模板）则是把文档和视图“粘合”起来，并管理其生命周期的粘合剂和调度中心。

为什么我们要花时间深挖这个看似“古老”的架构？因为即便在今天，当你维护遗留的MFC项目，或者使用BCG这样的第三方界面库来美化MFC程序时，你依然是在这个架构上添砖加瓦。BCG库提供了更漂亮的按钮、工具栏、皮肤，但应用程序的数据流、命令路由、文件序列化的核心逻辑，依然牢牢建立在文档/视图体系之上。不理解这个基础，你的界面美化工作就可能处处碰壁，比如不知道如何将BCG控件的数据与文档关联，或者无法实现多视图间的数据同步。这篇文章，我就结合自己多年踩坑的经验，带你彻底拆解MFC的文档/视图架构和应用程序框架，让你不仅能看懂，更能用好它。

2. 文档/视图体系结构深度解析

2.1 核心四类：CDocument, CView, CFrameWnd, CDocTemplate

MFC的文档/视图架构围绕着四个关键基类展开，它们各司其职，共同构成了应用程序的骨架。

CDocument（文档类）你可以把它想象成应用程序的“数据模型”或“后台数据库”。它的核心职责是：

1. 数据承载与管理：在CDocument的派生类中，你会定义成员变量来存储应用程序的核心数据。比如一个绘图程序，这里可能存着线条、形状的列表；一个文本编辑器，这里存着字符缓冲区。
2. 序列化支持：这是CDocument最强大的功能之一。通过重写Serialize(CArchive& ar)函数，你可以用几行代码就实现数据的保存到文件和从文件加载。MFC通过CArchive对象帮你处理了文件流的复杂操作。
3. 视图管理：一个文档对象内部维护着一个视图列表（CPtrList m_viewList）。当文档数据发生变化时，它可以调用UpdateAllViews(NULL)来通知所有关联的视图进行更新。
4. 修改标志：内置的SetModifiedFlag()和IsModified()方法，用于跟踪文档自上次保存后是否被修改，从而在关闭时提示用户保存。

CView（视图类）视图是数据的“呈现层”和“交互层”。它附着在一个框架窗口的客户区，主要工作是：

1. 渲染数据：在OnDraw(CDC* pDC)函数中，你需要编写代码，从关联的文档对象中获取数据，并将其绘制到设备上下文（CDC）上。这是视图最核心的任务。
2. 处理用户输入：通过重写OnLButtonDown,OnKeyDown等消息处理函数，视图接收用户的鼠标、键盘操作，并解释为对文档数据的修改请求。
3. 与文档通信：视图通过GetDocument()函数获得指向其关联文档的指针，进而读取或修改数据。视图对数据的修改，最终应通过文档提供的接口进行，或者修改后通知文档设置修改标志。

CFrameWnd（框架窗口类）框架窗口是视图的“容器”和“服务提供者”。它不仅仅是包含视图的那个带边框的窗口，更重要的是它提供了：

1. 用户界面容器：菜单栏、工具栏、状态栏这些UI元素都是由框架窗口创建和管理的。
2. 消息路由枢纽：许多命令消息（如菜单、工具栏按钮点击）首先发送到框架窗口，再由它根据当前活动视图和文档，通过MFC的命令路由机制（ON_COMMAND）分发到正确的处理函数。
3. 视图管理：框架窗口持有一个或多个视图，并通过SetActiveView、GetActiveView来管理当前活动的视图。

CDocTemplate（文档模板类）这是整个架构的“粘合剂”和“工厂”。它在应用程序初始化时（通常是InitInstance中）被创建，负责将文档、框架窗口、视图这三者动态地关联起来。它的核心作用：

1. 资源与类的关联：它把菜单、图标、加速键表等界面资源（Resource ID）与特定的文档类、框架窗口类、视图类绑定在一起。
2. 动态创建：当用户选择“文件”->“新建”或“打开”时，文档模板负责创建这三类对象的新实例，并将它们正确地组装起来。这是MFC运行时类型信息（RTTI）和动态创建（DECLARE_DYNCREATE/IMPLEMENT_DYNCREATE宏）能力的集中体现。
3. 类型管理：对于支持多种文档类型的程序（如一个程序既能处理文本文档又能处理图形文档），会有多个文档模板实例，每个实例管理一种文档类型。

注意：很多初学者会混淆CFrameWnd和CView。简单记：CFrameWnd是“框”，CView是“框里的画布”。用户直接交互（画图、打字）的是画布（视图），但框（框架窗口）负责提供菜单、调整画布大小等外围服务。

2.2 数据流与消息流：它们如何协同工作？

理解了静态结构，我们再看动态运行时，数据和控制流是如何在这些对象间传递的。这是理解MFC程序行为的关键。

典型的数据修改与更新流程：

1. 用户在视图CView中操作（例如，在绘图视图中画了一条线）。
2. 视图的消息处理函数（如OnLButtonUp）被调用。在这个函数里，视图不应该直接修改自己的私有变量来存储这条线。
3. 视图通过GetDocument()获得文档指针，调用文档的一个成员函数（例如AddLine(CPoint start, CPoint end)）来添加这条线。
4. 在文档的AddLine函数内部，将线条数据添加到文档维护的集合（如CArray）中，然后必须调用SetModifiedFlag(TRUE)标记文档已修改，接着调用UpdateAllViews(this, 0L, NULL)。
5. UpdateAllViews会遍历该文档的所有关联视图（除了调用时指定的pSender视图，这里传this就是排除当前视图），调用每个视图的OnUpdate函数。
6. 视图的OnUpdate函数默认实现是使视图的整个客户区无效，触发重绘。你可以重写OnUpdate进行优化，只使需要更新的部分区域无效（通过InvalidateRect）。
7. 最终，WM_PAINT消息导致视图的OnDraw被调用。在OnDraw中，视图再次通过GetDocument()获取最新的线条列表，并将它们全部绘制出来。

这个流程确保了数据的一致性和显示的同步。所有数据修改都集中在文档中，所有视图都从同一个数据源（文档）获取数据进行显示。

命令消息的路由流程：当用户点击一个菜单项或工具栏按钮时（假设ID是ID_EDIT_CUT）：

1. 命令消息首先发送到主框架窗口（CMainFrame）。
2. 框架窗口优先查看自己是否有对应的消息映射（ON_COMMAND(ID_EDIT_CUT, ...)）。通常，框架窗口只处理与窗口本身相关的命令（如ID_WINDOW_TILE）。
3. 如果框架窗口没有处理，它会将命令交给当前活动视图处理。视图检查自己的消息映射。
4. 如果视图也没有处理，命令会继续传递给与视图关联的文档对象。文档检查自己的消息映射。这是处理与数据相关命令（如ID_EDIT_CUT）的常见位置。
5. 如果文档仍未处理，命令会回退到应用程序对象（CWinApp派生类）进行处理。
6. 如果所有对象都未处理，该命令对应的UI元素（菜单项、工具栏按钮）会被框架自动禁用（变灰）。

这种“瀑布式”的路由机制，使得命令可以很自然地由最合适的对象来处理：视图处理显示相关的，文档处理数据相关的，框架处理窗口相关的。

2.3 单文档(SDI)与多文档(MDI)框架的差异

MFC应用程序向导让你选择创建单文档界面（SDI）或多文档界面（MDI）应用。它们的核心区别在于文档模板和框架窗口的管理。

单文档界面 (SDI):

• 文档模板：使用CSingleDocTemplate。顾名思义，它一次只管理一个打开的文档对象。当你选择“文件”->“新建”时，如果当前有已修改的文档，会提示保存，然后重用现有的文档、视图和框架窗口对象，只是用新数据重置它们。
• 框架窗口：通常只有一个主框架窗口类（CMainFrame，派生自CFrameWnd），它同时充当应用程序的主窗口和文档视图的容器。
• 特点：结构简单，类似于记事本。一次只能处理一个文档。

多文档界面 (MDI):

• 文档模板：使用CMultiDocTemplate。它可以管理多个同一类型的文档对象。每次“新建”或“打开”，都会创建一套全新的文档、视图和子框架窗口对象。
• 框架窗口：有两个关键的框架窗口类：
  1. 主框架窗口(CMainFrame，派生自CMDIFrameWnd): 这是应用程序的主窗口，包含菜单、工具栏、状态栏。它不直接包含视图，而是包含一个特殊的MDIClient窗口。
  2. 子框架窗口(CChildFrame，派生自CMDIChildWnd): 每个打开的文档都对应一个子框架窗口。子框架窗口位于MDIClient区域内，它内部包含实际的视图。用户可以平铺、层叠这些子窗口。
• 特点：功能强大，类似于Visual Studio或旧版Word。可以同时打开和编辑多个文档。

实操心得：在MDI应用中，为文档添加“窗口”->“新建窗口”功能（为同一文档创建另一个视图窗口）非常容易。文档模板和框架已经为你处理了大部分逻辑，你只需要在CChildFrame中处理视图的创建和关联即可。而在SDI中实现类似的多视图（如拆分窗口）则需要更精细的控制。

3. 应用程序框架的启动与初始化流程

一个MFC程序的启动不是从main或WinMain开始的，而是从你的应用程序类（如CMyApp）的InitInstance成员函数开始。理解这个初始化流程，对于调试启动问题和自定义初始化行为至关重要。

3.1 InitInstance：一切开始的地方

当你用向导生成一个MFC项目，在MyApp.cpp中一定会看到一个CMyApp::InitInstance()函数。这是应用程序的入口点。

标准SDI应用的InitInstance核心步骤：

1. 初始化公共控件库：调用InitCommonControlsEx确保ComCtl32.dll被加载，支持新的控件样式。
2. 创建并注册文档模板：这是最关键的一步。代码通常如下：

   CSingleDocTemplate* pDocTemplate; pDocTemplate = new CSingleDocTemplate( IDR_MAINFRAME, // 资源ID (菜单、图标、字符串等) RUNTIME_CLASS(CMyDoc), // 文档类 RUNTIME_CLASS(CMainFrame), // 主框架窗口类 (SDI) RUNTIME_CLASS(CMyView) // 视图类 ); if (!pDocTemplate) return FALSE; AddDocTemplate(pDocTemplate); // 将模板添加到应用程序的模板列表

   这段代码创建了文档、视图、框架窗口之间的“配方”。RUNTIME_CLASS宏和DECLARE_DYNCREATE/IMPLEMENT_DYNCREATE宏是实现动态创建的基础。
3. 处理命令行：调用CCommandLineInfo解析命令行参数。默认行为是，如果没有参数，就执行“新建”命令；如果跟了一个文件名，就执行“打开”命令打开该文件。

   CCommandLineInfo cmdInfo; ParseCommandLine(cmdInfo);

4. 分发命令：调用ProcessShellCommand(cmdInfo)。这个函数会根据cmdInfo的内容，命令文档模板去创建第一个文档、框架和视图。对于“打开”命令，它还会触发文档的Serialize函数来加载文件。
5. 显示窗口：获取主框架窗口指针并调用m_pMainWnd->ShowWindow(SW_SHOW)和UpdateWindow()。
6. 返回TRUE：如果初始化成功，返回TRUE，消息循环开始。

MDI应用的差异：在MDI中，InitInstance里创建的是CMultiDocTemplate，并且主框架窗口类派生自CMDIFrameWnd。ProcessShellCommand会创建主框架窗口，而第一个子窗口（文档）的创建则由后续的“新建”命令触发。

3.2 文档模板的幕后工作：动态创建与关联

当ProcessShellCommand执行一个“新建”命令时，文档模板（CDocTemplate）会执行一系列精密的操作：

1. 创建文档对象：调用RUNTIME_CLASS(CMyDoc)->CreateObject()动态创建文档实例。
2. 创建框架窗口对象：同样动态创建框架窗口实例（SDI是CMainFrame，MDI是CChildFrame）。
3. 创建视图对象：动态创建视图实例。
4. 建立关联：
   • 将视图附加到框架窗口的客户区（调用CFrameWnd::CreateView）。
   • 将文档与视图关联（调用CDocument::AddView）。
   • 将文档与文档模板关联。
5. 初始化资源：根据创建时传入的资源ID（如IDR_MAINFRAME），为框架窗口加载指定的菜单、图标、加速键表。
6. 发送初始化消息：依次调用新创建对象的OnNewDocument（文档）、OnInitialUpdate（视图）等初始化虚函数。

整个过程完全由框架驱动，你作为开发者，只需要在正确的类（文档、视图、框架）里重写对应的虚函数（如OnNewDocument,OnInitialUpdate,OnCreate）来插入自己的初始化代码即可。

注意事项：务必确保你的文档类、视图类、框架窗口类的头文件和实现文件中正确使用了DECLARE_DYNCREATE和IMPLEMENT_DYNCREATE宏。缺少它们会导致动态创建失败，程序在启动时崩溃，并可能抛出难以理解的调试断言。这是MFC新手最常见的坑之一。

3.3 资源ID（如IDR_MAINFRAME）的奥秘

你可能注意到，文档模板构造函数和很多地方都用到了IDR_MAINFRAME这个资源ID。它不是一个单一的资源，而是一个资源符号，在resource.h中定义，对应着资源文件（.rc）中的一组资源：

• 菜单：IDR_MAINFRAMEMENU
• 图标：IDR_MAINFRAMEICON (多个尺寸)
• 加速键表：IDR_MAINFRAMEACCELERATOR
• 字符串表：IDR_MAINFRAMESTRING (这个字符串有特殊格式，定义了文档类型名、默认文件名等)

框架会根据当前状态（如有无文档打开、文档是否修改）自动切换菜单。例如，当没有文档打开时，IDR_MAINFRAME菜单可能只显示“文件”和“帮助”。当打开一个文档后，框架会自动切换到包含“编辑”、“视图”等更多菜单项的菜单资源（通常也是IDR_MAINFRAME，但框架会合并文档模板指定的菜单）。

对于MDI应用，资源ID的用法更复杂一些。主框架窗口通常使用IDR_MAINFRAME，而子框架窗口（及其中包含的文档视图）使用另一个ID，如IDR_MYDOCTYPE。这允许你为不同类型的文档定义不同的菜单和图标。

4. 核心环节实现：从零构建一个自定义文档/视图应用

理论说再多，不如动手写一遍。假设我们要构建一个简单的“便签”应用，支持多文档，每个文档包含多行文本，并且我们想用BCGControlBar来美化界面。

4.1 步骤一：使用MFC应用程序向导创建项目

1. 打开Visual Studio，创建新项目，选择“MFC应用程序”。
2. 在“应用程序类型”中，选择“多文档界面(MDI)”，取消“文档/视图架构支持”的勾选？千万不要！我们就是要基于这个架构。保持勾选。
3. 在“复合文档支持”中，选择“无”。
4. 在“文档模板属性”中，设置文件扩展名，如“nt”（代表Note）。这会影响文件关联和默认过滤器。
5. 在“生成的类”页面，你会看到向导已经为你生成了四个核心类：CMyApp(应用),CMyDoc(文档),CMyView(视图),CMainFrame(主框架),CChildFrame(子框架)。
6. 完成创建。

4.2 步骤二：定义文档数据与序列化

打开MyDoc.h和MyDoc.cpp。文档类的职责是存储数据。

在CMyDoc类声明中添加数据成员：

// MyDoc.h class CMyDoc : public CDocument { protected: CStringArray m_strLines; // 使用CStringArray存储多行文本 // ... 其他成员 public: CStringArray& GetLines() { return m_strLines; } // 提供访问接口 void AddLine(const CString& strLine); // ... };

实现数据修改和序列化：

// MyDoc.cpp void CMyDoc::AddLine(const CString& strLine) { m_strLines.Add(strLine); SetModifiedFlag(TRUE); // 标记文档已修改 UpdateAllViews(NULL); // 通知所有视图更新 } // 序列化函数：实现数据的保存和加载 void CMyDoc::Serialize(CArchive& ar) { if (ar.IsStoring()) { // 保存：将字符串数组写入存档 ar << m_strLines.GetSize(); for (int i = 0; i < m_strLines.GetSize(); i++) { ar << m_strLines[i]; } } else { // 加载：从存档中读取字符串数组 int nCount; ar >> nCount; m_strLines.SetSize(nCount); for (int i = 0; i < nCount; i++) { ar >> m_strLines[i]; } } }

Serialize函数是文档类的灵魂。CArchive对象就像一个智能流，<<和>>运算符重载了基本类型和许多MFC集合类的读写。对于自定义复杂类型，你需要自己实现序列化。

4.3 步骤三：实现视图的绘制与交互

打开MyView.h和MyView.cpp。视图类的职责是显示和交互。

重写OnDraw函数进行绘制：

// MyView.cpp void CMyView::OnDraw(CDC* pDC) { CMyDoc* pDoc = GetDocument(); ASSERT_VALID(pDoc); // 调试断言，确保文档有效 if (!pDoc) return; // 设置文本属性 pDC->SetTextColor(RGB(0, 0, 0)); // 黑色文本 pDC->SetBkMode(TRANSPARENT); // 透明背景 CFont font; font.CreatePointFont(120, _T("宋体")); // 12点字体 CFont* pOldFont = pDC->SelectObject(&font); // 从文档获取数据并绘制 CStringArray& lines = pDoc->GetLines(); int y = 10; // 起始Y坐标 for (int i = 0; i < lines.GetSize(); i++) { pDC->TextOut(10, y, lines[i]); y += 20; // 行间距 } pDC->SelectObject(pOldFont); // 恢复旧字体 }

添加用户交互（例如，响应回车键添加空行）：首先在视图类的消息映射表(BEGIN_MESSAGE_MAP)中添加ON_WM_CHAR。

// MyView.cpp void CMyView::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags) { if (nChar == VK_RETURN) // 按下回车键 { CMyDoc* pDoc = GetDocument(); pDoc->AddLine(_T("")); // 添加一个空行 // 注意：AddLine内部已经调用了UpdateAllViews，视图会自动重绘 } else { // 其他字符处理... 这里简化，实际可能需要编辑某一行 CView::OnChar(nChar, nRepCnt, nFlags); } }

4.4 步骤四：集成BCGControlBar美化界面

BCG（Business Components Gallery）是一个强大的MFC扩展库，用于创建现代风格的UI。集成BCG通常意味着将你的框架窗口类从MFC标准类改为BCG的对应类。

1. 更改基类：在MainFrm.h和ChildFrm.h中，将CMainFrame的基类从CMDIFrameWnd改为CBCGPMDIFrameWnd，将CChildFrame的基类从CMDIChildWnd改为CBCGPMDIChildWnd。BCG的类提供了皮肤、自定义工具栏、Ribbon界面等高级功能。
2. 初始化BCG库：在应用程序类CMyApp::InitInstance()的开头，添加BCG库的初始化代码：

   CBCGPVisualManager::SetDefaultManager(RUNTIME_CLASS(CBCGPVisualManagerVS2012)); // 设置视觉样式 CBCGPDockManager::EnableDockBarMenu(); // 启用停靠栏菜单

3. 修改框架窗口创建：在CMainFrame::OnCreate函数中，你需要调用BCG父类的OnCreate，并添加BCG特色的控件，比如Ribbon Bar：

   if (CBCGPMDIFrameWnd::OnCreate(lpCreateStruct) == -1) return -1; // 创建并初始化Ribbon Bar if (!CreateRibbonBar()) { TRACE0("Failed to create ribbon bar\n"); return -1; } // ... 其他BCG控件初始化

4. 调整资源：BCG通常使用自定义的位图和XML资源来定义Ribbon界面。你需要按照BCG的文档准备这些资源，并在代码中加载。

踩坑实录：集成BCG后，一个常见问题是原有的MFC标准控件（如工具栏按钮）可能不显示或风格不一致。这是因为BCG的视觉管理器接管了绘制。解决方案通常是使用BCG提供的控件类（如CBCGPToolBar）替换原有的MFC控件类，或者在BCG初始化时设置兼容模式。另一个坑是，BCG的某些高级特性（如自定义皮肤）可能会与文档/视图架构中视图的绘制产生冲突，导致闪烁或残影。这时可能需要重写视图的OnEraseBkgnd返回TRUE，并确保在OnDraw中绘制整个客户区。

5. 高级主题与常见问题排查

5.1 实现多视图类型与拆分窗口

一个文档对应多个视图是文档/视图架构的核心优势。MFC提供了CSplitterWnd类来实现拆分窗口，让一个框架窗口内同时显示同一个文档的多个视图（可以是同类型或不同类型）。

创建静态拆分窗口（创建时固定窗格数）：

1. 在子框架窗口类CChildFrame中添加一个CSplitterWnd成员变量：CSplitterWnd m_wndSplitter。
2. 重写CChildFrame::OnCreateClient函数：

   BOOL CChildFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext) { // 创建一个1行2列的静态拆分窗口 if (!m_wndSplitter.CreateStatic(this, 1, 2)) { TRACE0("Failed to create static splitter\n"); return FALSE; } // 在每个窗格中创建视图。0,0是左上角窗格，0,1是右上角窗格。 if (!m_wndSplitter.CreateView(0, 0, RUNTIME_CLASS(CMyListView), CSize(200, 0), pContext) || !m_wndSplitter.CreateView(0, 1, RUNTIME_CLASS(CMyTextView), CSize(0, 0), pContext)) { TRACE0("Failed to create splitter views\n"); return FALSE; } // 设置活动视图（可选） SetActiveView((CView*)m_wndSplitter.GetPane(0, 1)); return TRUE; // 返回TRUE，表示我们自己已经创建了客户区 }

   这里假设我们有两个不同的视图类：CMyListView（左侧列表视图）和CMyTextView（右侧文本视图）。它们需要关联到同一个文档类型。

关键点：

• 传递给CreateView的pContext参数包含了文档模板信息，框架会自动将新创建的视图与当前活动的文档关联。
• 你需要为CMyListView和CMyTextView也创建对应的文档模板吗？不需要。它们共享父框架窗口（CChildFrame）创建时所用的文档模板关联的文档。拆分窗口内的视图通过pContext自动关联到当前文档。
• 动态拆分窗口（用户可动态拖动分割条创建新窗格）使用CreateDynamic方法，逻辑类似但更复杂。

5.2 自定义序列化与版本控制

当你的文档数据结构发生变化时（例如，在CMyDoc中新增了一个成员变量m_nVersion），直接序列化可能会出问题。旧版本的文件无法被新版本的程序正确读取。这就需要版本控制。

在Serialize函数中加入版本判断：

void CMyDoc::Serialize(CArchive& ar) { if (ar.IsStoring()) { // 保存时，先写入一个版本标识 ar << (WORD)2; // 版本2 ar << m_strLines; ar << m_nVersion; // 保存新增加的成员变量 } else { // 加载时，先读取版本号 WORD wVersion; ar >> wVersion; if (wVersion == 1) { // 处理版本1的文件格式 ar >> m_strLines; m_nVersion = 1; // 为旧数据设置默认值 // 可能需要在这里进行数据迁移，将v1格式转换为v2格式 MigrateFromV1ToV2(); } else if (wVersion == 2) { // 处理版本2的文件格式 ar >> m_strLines; ar >> m_nVersion; } else { // 未知版本，抛出异常或处理错误 AfxThrowArchiveException(CArchiveException::badSchema); } } }

这是一种简单的版本控制方法。更复杂的系统可能会使用一个序列化函数专门处理数据迁移。

5.3 常见问题排查速查表

在开发基于文档/视图的MFC应用时，你几乎一定会遇到下面这些问题。这里给出排查思路。

5.4 性能优化与注意事项

• 避免在OnDraw中执行复杂计算：OnDraw会被频繁调用。应将耗时的数据准备或计算工作放在文档或其他地方，OnDraw只负责快速绘制。
• 合理使用OnUpdate：默认的OnUpdate使整个客户区无效。对于只有小部分区域变化的复杂视图，重写OnUpdate，根据提示信息（lHint,pHint）只使需要更新的区域无效，可以大幅减少闪烁和提高性能。
• 管理大型文档：当文档数据量极大时，一次性加载到内存（在Serialize中）可能不可行。考虑实现“懒加载”或分页机制，文档只管理数据的索引和当前页，视图根据需要请求文档加载特定部分的数据。
• 线程安全：如果后台线程需要更新文档数据，绝对不能直接在线程中调用文档的修改函数或UpdateAllViews。必须通过Windows消息（如PostMessage）将更新请求发送到主UI线程，由主线程执行修改和更新视图的操作。因为所有UI操作都必须在创建窗口的线程（通常是主线程）中进行。

文档/视图架构是MFC的基石，它强制了一种清晰的数据与UI分离的设计模式。尽管MFC本身已不再是新技术前沿，但理解这套架构的思想，对于处理遗留项目、学习经典设计模式，乃至理解其他GUI框架（如Qt的Model/View）都大有裨益。当你需要为这样的应用换上BCG这样的现代界面时，你会发现，只要基石稳固，外立面的翻新工作就会有条不紊。