将 MFC 文档/视图转换为？
我的问题很难形成，但首先：
我有一个 MFC SDI 应用程序，我已经工作了很长一段时间，它似乎从来不适合文档/视图架构。即文档中没有任何有用的内容。它是多线程的，我需要在线程等方面做更多的事情。
我梦想也将它移植到 Linux X Windows，但我对那个编程环境还一无所知。也许麦克也是。
我的问题是从这里去哪里？
我想我想从 MFC Doc/View 转换为带有消息循环和窗口过程等的直接 Win API 内容。但任务似乎很艰巨。
Linux X Windows 环境是否使用类似的消息循环、窗口过程架构？
我可以分道扬镳吗？就像一次转换一点点而不会使我的程序长时间无法使用？
稍后添加：
我的程序是一个文件比较程序（听起来很简单。）因此，用一种简单的方式说明我的困惑，通常一个文档可以有多个视图，但在这个应用程序中，我有一个视图包含多个（两个）文档（文件）。我有一个“比较引擎”，是我在 DOS 时代第一次写的，它是程序的核心，而视图只是查看该例程的输出。有时我认为我的一些“视图”代码在“文档”类中可能有意义，但我几乎不知道从哪里开始将其分成更多类。我最近开始阅读《Windows 编程》第五版。作者：Charles Petzold（我知道这已经过时了 (C) 1998），希望能更好地理解直接 Windows 编程。
我对 C#、NET、MFC、MVC、Qt、wxWidgets 等选项的激增感到不知所措。
我发现我经常在尝试理解 MFC 框架中发生的事情时陷入困境，因为我的代码中的某些内容无法正常工作看起来应该是这样，但问题是我不太明白MFC是如何在后台处理事情的。这就是为什么我试图学习“直接 Windows 编程”，其中我的程序包含我编写的所有消息传递代码。我希望这有助于对我的问题有足够的了解，以便有人可以指导我。
My question will be hard to form, but to start:
I have an MFC SDI app that I have worked on for an embarrassingly long time, that never seemed to fit the Doc/View architecture. I.e. there isn't anything useful in the Doc. It is multi-threaded and I need to do more with threading, etc.
I dream about also porting it to Linux X Windows, but I know nothing about that programming environment as yet. Maybe Mac also.
My question is where to go from here?
I think I would like to convert from MFC Doc/View to straight Win API stuff with message loops and window procedures, etc. But the task seems to be huge.
Does the Linux X Windows environment use a similar kind of message loop, window procedure architecture?
Can I go part way? Like convert a little at a time without rendering my program unusable for long periods of work?
Added later:
My program is a file compare program (sounds simple enough.) So, stating my confusion in a simple way, normally a document can have multiple views, but in this app, I have one view with multiple (two) documents (files). I have a "compare engine" that I first wrote back in the DOS days, that is the heart of the program and the view is just looking at the output of that routine. Sometimes I think that some of my "view" code could make sense in a "document" class but I hardly know where to begin to separate it into more classes. I have recently started reading "Programming Windows" 5th Ed. by Charles Petzold, (I know that is quite out of date (C) 1998) hoping to get a better understanding of direct Windows programming.
I get overwhelmed with the proliferation of options like C#, NET, MFC, MVC, Qt, wxWidgets, etc.
I find I am often stuck trying to understand something going on in the MFC framework because something in my code doesn't work as it seems it should, but the problem is that I don't really understand how MFC is handling things in the background. That is why I am trying to learn "straight Windows programming" where my program has all the message passing code that I write. I hope this helps give enough insight into my question so someone can guide me on my way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
X 的工作方式非常不同，原始 Windows 程序和原始 X 程序可能根本无法共享太多 UI 代码。
如果您想要两者之间的可移植性，那么您很可能想要使用 Qt 或 wxWidgets 之类的东西。在两者中，wxWidgets 与 MFC 更相似，因此它可能需要较少的重写，但会（或多或少）保持您在您想要的内容和它提供的内容之间看到的相同“脱节”。
如果不了解有关您的应用程序的更多信息，以及为什么它与 MFC 不太适合，就不可能猜测 Qt 是否更适合。直接的猜测是“可能不会”。
MFC 使用“文档/视图”架构，而 Qt 使用原始的模型-视图-控制器架构。在大多数情况下，MFC 的 Document 类基本上相当于一个模型和一个控制器合而为一——因此，如果您的文档不包含任何有用的内容，那么在 Qt 中您显然会同时拥有一个模型和一个控制器，两者都没有做太多的事情。有用。
也就是说，我必须提出一个问题，为什么您的文档目前没有太多作用。 MVC 模式已被证明适用于各种各样的问题，因此，虽然它可能不能很好地解决您的问题，但也有可能它可以很好地工作，而您只是没有使用它。如果不知道更多关于你在做什么的信息，就不可能猜测到这一点。
编辑：好的，澄清很有帮助。首先要认识到的是，文档并不一定等同于文件。恰恰相反，一个文档可以完全合理地与任意数量的文件相关。
举个例子，考虑一个网络浏览器。构成当前显示的页面所需的所有数据都合理地属于同一文档的一部分。根据您的观点，这要么是零个文件，要么是一大堆文件（它将作为来自服务器的任意数量的文件开始，但不一定在本地存储为文件）。将其中任何内容存储为本地文件将是（或多或少）缓存的意外副产品，并且大多数与浏览本身无关。
在您的情况下，您可能会将两个（或三个？）文件读入内存并将它们与某种数据结构一起存储以保存比较结果。比较完成后，您可能会也可能不会丢弃文件本身的内容。我认为可以肯定地说，“正常”的职责分离是数据和生成该数据的代码位于文档中。
视图应该仅包含从该数据结构获取结果并将其显示在屏幕上的代码。通常您想要在视图中存储的几乎唯一数据是与数据呈现方式相关的数据（例如，缩放级别或当前滚动位置等）。同样，视图中的代码应该只与显示结果和对用户输入做出反应有关，而不是首先“创建”数据。
因此，我认为您的程序可以被重写以更有效地使用文档/视图模式，或者可以被重写以使用 MVC。反过来，这意味着 Qt 的移植可以/可能会很好地工作——前提是您愿意花一些时间和精力来理解它的工作原理，然后对您的代码进行可能相当大的更改按照设计的方式工作。
正如我之前评论的，wxWidgets 在这方面更像 MFC ——它使用文档和视图，而不是模型、视图和控制器。如果您按照设计的方式进行一些重写以分离职责，它也会发挥最佳作用。好处是，一次一步地执行此操作可能会更容易一些：在您已经熟悉的 MFC 中重写代码，然后将其移植到 wxWidgets ——但是考虑到两者之间的相似性， “Port”可能只不过是小的编辑——通常只需将一些名称从 C* 更改为 wx* 就足够了。据我回忆，我唯一遇到大量工作的地方是创建菜单——使用 MFC，它们通常通过资源进行处理，但是（至少几年前我使用它时）wxWidgets 通常直接公开以下代码：创建了菜单条目。
移植到 Qt 可能会需要更多工作——您几乎必须学习一个新框架，并且同时大幅重新组织您的代码。好处是，当你完成后，结果可能会更清晰一些，尽管考虑到你正在做的事情，差异可能很小。在文档/视图中，视图显示数据并对用户输入做出反应。在模型/视图/控制器中，视图仅显示数据，但用户输入（修改底层数据）通过控制器。由于您（大概）不希望修改底层数据，因此在任何情况下，涉及的唯一用户输入可能都属于视图（例如，滚动等）。您几乎不可能在文档/模型中放置一些可以更改的内容（例如，用户选择的当前字体或颜色等）。
X works enough differently that a raw Windows program and a raw X program probably wouldn't be able to share much UI code at all.
If you want portability between the two, chances are pretty good that you want to use something like Qt or wxWidgets. Of the two, wxWidgets is more similar to MFC, so it would probably require less rewriting, but would maintain (more or less) the same "disconnect" you're seeing between what you want and what it provides.
Without knowing more about your application, and why it doesn't fit well with MFC, it's impossible to guess whether Qt would be a better fit or not. An immediate guess would be "probably not".
MFC uses a "document/view" architecture, where Qt uses the original Model-View-Controller architecture. For the most part, MFC's Document class is equivalent basically a Model and a Controller rolled into one -- so if your Document contains nothing useful, in Qt you'd apparently have both a Model and a Controller, neither of which did much that was useful.
That said, I have to raise a question about why your Document currently doesn't do much. The MVC pattern has proven applicable to a wide variety of problems, so while it's possible it can't work well for your problem, it's also possible that it could work well, and you're simply not using it. Without knowing more about what you're doing, it's impossible to even guess at that though.
Edit: Okay, the clarification helps quite a bit. The first thing to realize is that a Document does not necessarily equate to a file. Quite the contrary, a document can perfectly reasonably relate to an arbitrary number of files.
Just for example, consider a web browser. All the data needed to compose the page its currently displaying would reasonably be part of the same document. Depending on your viewpoint, that's either zero files, or a whole bunch of them (it will start as an arbitrary number of files coming from the server(s), but won't necessarily be stored as files locally at all). Storing any of it as a file locally will be a (more or less) accidental by-product of caching, and mostly unrelated to browsing per se.
In your case, you're presumably reading the two (or three?) files into memory and storing them along with some sort of data structure to hold the result of the comparison. After the comparison is complete, you might or might not discard the contents of the files themselves. I think it's safe to say that the "normal" separation of responsibilities would be for that data and the code that produces that data to be in the Document.
The View should contain only the code to take that result from that data structure, and display it on screen. Nearly the only data you normally want to store in the View would be things related to how the data is presented (e.g., things like a zoom level or current scroll position). Likewise, the code in the view should relate only to displaying the result and reacting to user input, NOT to "creating" the data in the first place.
As such, I think your program could be rewritten to use the Document/View pattern more effectively, or could be rewritten to use MVC. That, in turn, means a port to Qt could/would probably work just fine -- provided you're willing to put some time and effort into understanding how it's intended to work and then make what may be fairly substantial changes to your code to work the way it's designed to.
As I commented previously, wxWidgets is more like MFC in this respect -- it uses a Document and View, not a Model, View, and Controller. It's also going to work best if you do some rewriting to separate responsibilities the way it's designed for. The good point is that it's probably a bit easier to do that one step at a time: rewrite the code in MFC, which which you're already familiar, and then port it to wxWidgets -- but given the similarity between the two, that "Port" will probably be little more than minor editing -- often just changing some names from C* to wx* is just about enough. To my recollection, the only place I've run into much work was in creating menus -- with MFC they're normally handled via resources, but (at least a few years ago when I used it) wxWidgets normally directly exposed the code that created the menu entries.
Porting to Qt would probably be more work -- you pretty much have to learn a new framework, and substantially reorganize your code at the same time. The good point is that when you're done, the result will probably be somewhat cleaner, though given what you're doing, the difference may be pretty minor. In a Document/View, the View displays data, and reacts to user input. In a Model/View/Controller, the View only displays data, but user input (that modifies the underlying data) goes through the Controller. Since you (presumably) don't expect to modify the underlying data, the only user input involved probably belongs in the view in any case (e.g., things like scrolling). It's barely possible you might have a few things you could put in the Document/Model that would be open to change (e.g., things like the current font or colors the user has selected).