如何解决在.NET API中包装MFC Doc / View应用程序的最佳方法？
| 我目前有一个使用doc / view体系结构的MFC项目（宽松地）。该应用程序包含所有业务逻辑以及GUI代码。我正在寻找一种可以通过.NET访问的类似API的访问方式。为此，我想尽量减少重写，所以我想知道这些选项是什么？ 有没有办法在仍然按原样利用MFC输入/启动功能的同时在MFC应用程序周围合并.NET接口？这样就可以运行当前应用程序，并让另一个应用程序动态获取该应用程序的句柄并利用API？ 还有其他更有意义的方法吗？ [编辑] 最终目标是将业务逻辑分解为一个库和GUI，以建立某种新框架（winforms，wpf等）……目前，我正在寻找实现基本目标的第一个目标的方法。来自第三方应用程序的API控制。掌握了这些知识之后，是否值得进行COM接口的中间步骤，然后最终将逻辑放入库中以编写用于基本API访问的.net包装器，从而最终完成该逻辑？解决方法
你到底想要什么？是否要为第三方提供API以驱动您的应用程序？还是真的要用.NET UI替换MFC UI？
如果是前者，那么答案是COM。从.NET可以看到COM，因此，如果您的MFC应用程序支持COM接口，则.NET应用程序可以通过它进行调用。
我目前正在使用完全支持您描述的MFC应用程序。我们的EXE公开了一个COM接口，该接口可以由用C ++，C＃，VB甚至Java编写的其他应用程序驱动。
[根据您的编辑进行编辑]
如果最终要用WinForms / WPF UI替换MFC UI，则可以将现有的C ++业务代码包装在C ++ / CLI中，然后从C＃中访问它。在您的方案中，添加COM API并不是真正的中间步骤。如果您真正想做的是替换UI，那么这是很多工作，可能不值得。
您可以参考此问题，以阅读我的详细经验，以WPF替换MFC UI。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。