linux - 转换MFC Doc/View到？

Question

我的问题很难形成，但要开始:

我有一个令人尴尬的工作了很长时间的MFC SDI应用程序，它似乎从来都不适合Doc/View体系结构。即文档中没有任何有用的信息。它是多线程的，我需要在线程等方面做更多的工作。

我梦dream以求也将其移植到Linux X Windows，但是我对该编程环境还一无所知。也许Mac也是如此。

我的问题是从这里去哪里？

我想我想从MFC Doc/View转换为带有消息循环和窗口过程等的直接Win API东西。但是任务似乎很庞大。

Linux X Windows环境是否使用类似的消息循环，窗口过程架构？

我可以分开吗？想要一次转换一点而不会使我的程序长时间不能使用？

稍后添加:

我的程序是一个文件比较程序(听起来很简单。)因此，以一种简单的方式说明我的困惑，通常一个文档可以具有多个 View ，但是在此应用程序中，我的一个 View 包含多个(两个)文档(文件)。我有一个“比较引擎”，这是我在DOS时代第一次写的，它是程序的核心， View 只是在查看该例程的输出。有时我认为我的某些“ View ”代码在“文档”类中可能有意义，但我几乎不知道从哪里开始将其分为更多类。我最近开始阅读“Programming Windows”第5版。由Charles Petzold撰​​写，(我知道这已经过时了(C)1998年)，希望能更好地理解直接Windows编程。

我对C#，NET，MFC，MVC，Qt，wxWidgets等选项的泛滥感到不知所措。

我发现我经常被困在试图理解MFC框架中发生的事情，因为我的代码中的某些内容似乎无法正常工作，但是问题是我不太了解MFC如何在后台处理事情。 。这就是为什么我试图学习“直接Windows编程”的原因，其中我的程序具有我编写的所有消息传递代码。我希望这有助于对我的问题有足够的了解，以便有人可以引导我前进。

Answer 1

X的工作方式完全不同，以至于原始Windows程序和原始X程序可能根本无法共享很多UI代码。

如果您希望两者之间具有可移植性，那么很可能要使用Qt或wxWidgets之类的东西。在这两者中，wxWidgets与MFC更相似，因此它可能需要较少的重写，但将(或多或少)维持您在所需内容和提供的内容之间看到的相同“断开连接”。

如果不了解您的应用程序以及为什么它与MFC不太匹配，就无法猜测Qt是否会更好。立即猜测可能是“可能不是”。

MFC使用“文档/ View ”体系结构，其中Qt使用原始的“模型- View - Controller ”体系结构。在大多数情况下，MFC的Document类基本上等效于一个Model和一个Controller合并成一个类-因此，如果您的Document不包含任何有用的内容，那么在Qt中，您显然会同时拥有Model和Controller，而这两者所做的工作都不多有用。

就是说，我不得不提出一个问题，为什么您的文档当前没有做很多事情。 MVC模式已被证明适用于各种各样的问题，因此尽管它可能无法很好地解决您的问题，但也可能它可以很好地工作，而您根本就没有使用它。如果不了解自己在做什么，尽管如此，甚至无法猜测。

编辑:好的，澄清有很大帮助。首先要意识到的是，文档不一定等于文件。恰恰相反，文档可以完全合理地与任意数量的文件相关。

例如，考虑使用Web浏览器。构成其当前显示的页面所需的所有数据都将合理地属于同一文档。根据您的观点，它要么是零个文件，要么是一整堆文件(它将以来自服务器的任意数量的文件开始，但不一定完全存储为本地文件)。将其中的任何一个存储为本地文件将(或多或少)是缓存的偶然副产品，并且几乎与浏览本身无关。

在您的情况下，您大概是将两个(或三个？)文件读取到内存中，并将它们与某种数据结构一起存储以保存比较结果。比较完成后，您可能会也可能不会放弃文件本身的内容。我认为可以肯定地说，“正常”的职责分离是针对该数据以及生成该数据的代码在文档中。

View 应仅包含从该数据结构获取结果的代码，并将其显示在屏幕上。通常，您通常要在 View 中存储的唯一数据几乎就是与数据显示方式相关的事物(例如，缩放级别或当前滚动位置之类的事物)。同样， View 中的代码应仅与显示结果和对用户输入作出 react 有关，而不与首先“创建”数据有关。

因此，我认为您的程序可以重写为更有效地使用Document/View模式，或者可以重写为使用MVC。相应地，这意味着移植到Qt可能会/可能会很好-前提是您愿意花一些时间和精力来了解它的工作原理，然后对您的代码进行相当大的更改以按照设计方式工作。

正如我之前评论的那样，wxWidgets在这方面更像MFC，它使用的是Document和View，而不是Model，View和Controller。如果您进行一些重写以按照其设计的方式来划分职责，那么它也将最好地工作。好处是，一次完成一个步骤可能会更容易一些:在MFC中重写您已经熟悉的代码，然后将其移植到wxWidgets中，但是鉴于两者之间的相似性， “端口”可能只不过是次要的编辑而已-通常只需将某些名称从C *更改为wx *就足够了。回想起来，我唯一要做的工作就是创建菜单-使用MFC，它们通常是通过资源来处理的，但是(至少在几年前，当我使用它时)wxWidgets通常直接公开了创建菜单项。

移植到Qt可能需要做更多工作-您几乎必须学习一个新框架，并在实质上同时重组代码。好处是，完成后，结果可能会更清晰一些，尽管根据您的操作，两者之间的差异可能很小。在文档/ View 中， View 显示数据，并对用户输入使用react。在模型/ View / Controller 中， View 仅显示数据，但用户输入(修改基础数据)通过 Controller 。由于您(可能)不希望修改基础数据，因此在任何情况下(例如，诸如滚动之类的东西)，涉及的唯一用户输入都可能属于 View 。您几乎不可能在文档/模型中放一些可以更改的内容(例如，当前字体或用户选择的颜色之类的内容)。