在 COM 服务器中使用 MFC - 我有哪些选择？

Question

Visual C++。我必须实现一些绘图和打印功能，这些功能将被合并到（其他开发人员的）COM dll 中。首先，我想使用纯 GDI 来做所有事情，仅此而已，但与 MFC 实现相比，在 GDI 中完成打印和打印预览似乎是一项艰巨的工作。所以我决定专注于MFC。这里有个小问题：我的选择对吗？我的意思是，在没有 MFC 的情况下实现打印（和打印预览）的任何简单方法？

既然我需要 MFC（假设你也同意这一点），我有两个关于如何做的问题：

1）我认为COM dll是ATL项目（不是我的代码，其他一些开发人员独立开发的）。我可以在那个 dll 中启用 MFC 支持吗？在 COM 服务器中使用 MFC 运行时有哪些风险/限制/缺点？如果您建议这样做，我该怎么做？

2) 尽管我想尽可能少地影响第三方 COM 服务器的代码，但我认为将我的代码实现为单独的基于 MFC 的 DLL 并加载和使用该 DLL 可能是更好的方法来自 COM 服务器。你建议这样做吗？在这种情况下有什么风险/限制/缺点？

简而言之，我想在我的代码中使用 MFC 的绘图，尤其是打印功能，它本身应该集成到另一个开发人员的 COM dll 中（它本身用于大型企业应用程序）。我不是COM技术专家，所以我有点困惑。我的最佳选择是什么？

Answer 1

您可以在您自己的 dll 内部使用 MFC，并通过非 MFC 侵入功能向您的用户公开功能：例如，如果您需要从/向 ypur 调用者传递一个点，请使用 GDI 标准 POINT 结构，然后将其转换到一个 CPoint 内部使用。在这种情况下，您不需要在 ATL 项目中启用 MFC 的使用（无论如何都是可能的），但您当然需要分发或链接 MFC dll。如果你想保持调用者 com dll 尽可能干净，你当然可以创建自己的 ATL+MFC dll 并通过 com 接口公开你的函数，但请保留 mynd 以避免将 MFC 相关对象放入接口中。

Answer 2

除非您使用 MFC Document/View Architecture，否则打印和打印预览是一项非常麻烦的工作。你的 COM 会公开这么高级的 UI 吗？

如果你的 COM 必须独立于 .NET，那么 MFC 就是要走的路，否则我会使用 .NET。如果您选择 MFC，请确保静态链接到它。否则，您很可能会在缺少必要的 MFC 版本的机器上遇到运行时错误。

除此之外，我不会担心兼容性，因为 COM 的想法是让底层的魔法来进行整数、字符串和其他对象的编组。