WPF、Win32、MFC的难题问题

Question

WPF、Win32、MFC的难题问题

wpfwinapiapimfc

10

假设您是一名具有C++和C#基础知识的IT学生。假设您想设计以下应用程序：

需要提供某些性能，如压缩程序、加密算法、编解码器
使用了一些系统调用
具有图形用户界面

并且您想学习一个API，使您能够编写像上述应用程序一样的应用程序，并且：

是主流的
是未来可靠的
使您有机会找到一份体面的工作
足够易学 - 我的意思是像VCL那样易学，而不是像WinAPI那样难学

那么，在这些假设的情况下，您会选择哪个API？MFC、WPF还是其他？我非常喜欢VCL和QT，但它们并不主流，我认为很少有雇主会要求您使用QT或Visual C++ Builder编写应用程序...

感谢回答。

- Mack

1

假设你是一名IT学生，具备C++和C#的基础知识。现在我们知道你是一名IT学生了。 :-) - Ashish Gupta

2个回答

7

如果你喜欢使用C＃编程并且熟悉.Net框架，我建议你了解一下WPF。WPF是一个非常棒的GUI框架，你可以做任何事情 - 并让它闪耀！WinForms可能更容易理解，但我认为WPF更具“未来性”。另一个积极的方面是，WPF与Silverlight非常相似，因此如果你掌握了WPF，应该也能编写Silverlight应用程序 - 如果感兴趣的话。请不要费心学习MFC...我无法相信还有很多人在使用MFC，除非他们之前正在使用它，并且没有机会改变..

现在有很多适合.Net程序员的好工作，因此除了C＃和.Net框架的一般知识外，能够处理一些GUI框架也是值得的。

当涉及到您提到“能够像归档程序、加密算法、编解码器一样提供一些性能”时，这确实不应该取决于您选择的GUI框架。这种代码将在GUI层之外的层中编写，并且通常会绑定到GUI。使用WPF，您可以使用C#在某个独立于GUI层的类中编写例如加密算法，然后在WPF中编写的View将绑定到C#代码并从此处获取其答案。但是，如果您使用WinForms，仍将执行相同的操作，性能取决于算法-而不是GUI。

关于开始使用WPF，SO上有很多问题帮助您。因此，您应该可以通过快速搜索找到良好的帮助。

祝你好运！

- stiank81

好的，感谢您的回答。WPF看起来很不错。但是我不理解“这种代码将在GUI层外部编写，并且通常将绑定到GUI。”这部分的意思。您的意思是我要分别使用WPF编写GUI和使用原始CPU功率编写代码，然后以某种神奇的方式将它们链接在一起吗？这意味着使用非托管C++和Interop吗？ - Mack

没有非托管的C ++，也没有Interop - 除非你想要。没有什么魔法可言。考虑你用C＃编写一个处理复杂算法的类。现在，你可以编写一个显示结果的控制台应用程序 - 或者你可以编写一个WPF应用程序。性能取决于处理算法的类库 - 而不是显示结果的GUI。当涉及到动画和花哨的GUI内容时，GUI上的性能大都是相关的，而这在WPF中处理得非常好。 - stiank81

谢谢，我会选择C# + WPF的路线。这两者都是足够好的新技术。我只是不确定C#在涉及桌面程序时是否能提供足够的性能。 - Mack

C# 真的可以提供出色的性能。如果您有一些非常时间关键的部分，其中它不够好，您可以使用另一种语言编写这些部分，并将其作为非托管代码托管在 C# 应用程序中。祝你好运！ - stiank81

1

+1 对于“提供像压缩程序、加密算法、编解码器等性能”的要求，不应该依赖于你选择的 GUI 框架。 - fretje

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- stakx - no longer contributing · Accepted Answer

注意：以下答案是几年前针对桌面应用程序开发编写的。如今（2018年），您可能只需构建Web应用程序，即可获得相对跨平台和设备无关的东西。（例如，在服务器端使用ASP.NET Core，与客户端使用UI框架/库（如React、Vue.js或Angular）配合使用）。

- Win32 API - 如果我是你，我会忘记它。只有在使用纯C编程时，或者确实需要进行大量系统调用时，或者担心更“舒适”的平台或框架（例如下面提到的框架）引入的额外开销时，才直接通过Win32 API编程Windows应用程序。直接通过Win32 API编程UI很繁琐、混乱，需要处理许多细节。它也完全不跨平台，但您可能或可能不关心这一点。 - MFC - 如果您正在使用C++并且固定在Windows平台上，则可能是一个选择。除了使Win32 API变得更加舒适外，我从未理解它的其他优点（据我所知，它基本上是Win32 API的面向对象包装器的集合，消除了一些复杂性/混乱）。此外，它也不是非常跨平台。 - Qt，wxWidgets - 相当广泛的UI框架。在平台独立性发挥作用的地方可能是不错的选择。据我所知，这两个框架都针对C++语言。 - WinForms（.NET） - 与MFC类似，也基于Win32 API（USER32和GDI +）。据我所知，WinForms框架现在正在移植到Mono，并因此具有某种跨平台性。但是，它并不是最新的技术。对于复杂的UI，有时也可能有些缓慢。如果今天我必须决定使用哪个框架，我宁愿选择...：

WPF (.NET) -- 拥有比WinForms更现代的图形能力，且据说渲染速度更快，因为它不再基于Win32 API（GDI）。同时它运行在.NET上，我认为这是一个非常好的平台来进行开发。在我的看法中，使用C#编程比使用C++更容易，这也是反对Win32 API、MFC、Qt和wxWidgets的理由之一。需要注意的是，WPF目前只存在于Windows平台上而不是跨平台的。

当然还有Java，包括与它一起提供的UI框架。我不是Java专业人员，所以不能多说什么，但我想象Java可能是实现平台独立性的最佳选择；并且在某些行业（例如移动电话、银行）中，由于其非常稳定的JVM和安全考虑，Java是比.NET更具支配地位的平台。

因此，我的建议是选择.NET框架和WPF UI，如果您打算大部分时间都留在Microsoft的世界中。请记住，您仍然可以通过P/Invoke使用Win32 API（这是最接近"系统调用"的方法）。