主机中的 MFC GUI 和其他需要 GUI 的 DLL答案

【问题标题】：MFC GUI in main frame and other DLLs that nedd also GUI主机中的 MFC GUI 和其他需要 GUI 的 DLL
【发布时间】：2010-10-24 10:03:23
【问题描述】：

我有一个 MFC 应用程序，它的 GUI 实现为可执行代码的一部分（view-doc 体系结构等）我的应用程序使用了一些我编写的 DLL。

现在我必须编写另一个 DLL，我知道它也必须有一个 GUI。

我的问题/不确定性是我应该将 GUI 实现为主应用程序（主 GUI）的一部分并在它们之间进行连接，还是应该将 GUI 实现为新 DLL 的一部分并在主 GUI 中创建一个入口点？在这两种情况下，我都清楚我必须有一个接口类。

如果我将 GUI 实现为 DLL 的一部分，我很清楚 GUI 应该保存指向接口类的指针，但接口类应该如何与 GUI 对话（例如，通知 GUI 一个长操作是完成或提供有关操作的 GUI 中间报告？ 1) 使用从接口到 GUI 的指针？ 2）使用带有回调的消息循环？ 3) 其他选项？？？

非常感谢

【问题讨论】：

【解决方案1】：

通常，DLL 中的 MFC + GUI 内容 = 很多不必要的麻烦。至少我十多年前记得。它与 MFC 微软风格的“支持”有关，以支持微软某些人认为可能是问题的东西，因此 MFC 区分不同类型的 DLL 和 DLL 状态等等，特别是在资源方面。

所以我想说，对于 MFC，如果可行的话，请将 GUI 内容保留在主程序中。

这也与责任分配有关。通过分离职责，您可以获得更简洁、更易于维护的设计。将知识放在职责需要的地方。

干杯，

【讨论】：

同意。在 MFC 中管理 DLL 和 EXE 之间的资源状态令人头疼。
+1 - 将所有 GUI 保留在 main 中 - 重新设计 DLL 接口，使其与 GUI 分离 - 无论如何这是一个好主意，将 GUI 代码与“真实”代码分开会导致更多重用“真正的”代码。
坦率地说，我不关心单独 GUI 的困难。我只关心好的设计和好的编码习惯。
假设我将 GUI 代码与“真实”代码分开 - 当有变化时我应该如何通知 GUI？我不想使用回调，因为它们不是面向对象的。 “观察者”设计模式是个好主意吗？
@David：分离和好的设计是一回事。 :-) MFC 已经对简化的模型-视图-控制器（参见 Wikipedia 文章）、CView 和 CDocument 类提供了一些支持。我不喜欢 MFC 的版本，但如果做一个 MFC 应用程序，我会顺其自然，可以这么说。在您的 DLL 中，您将执行类似于 CDocument 的操作，或者甚至可能是 CDocument 派生类。查看有关 MFC 特定内容的文档（例如，请参阅 AFX_MANAGE_STATE）。