在.NETAPI中包装MFC文档/视图应用程序的最佳方法？

我目前有一个MFC项目（松散地）利用了doc/view架构。此应用程序包含所有业务逻辑以及GUI代码。我希望提供一个类似API的访问，可以通过.NET访问。在这样做的过程中，我希望尽量减少重写，所以我想知道有哪些选项

有没有一种方法可以在MFC应用程序周围加入一个.NET接口，同时仍按原样使用MFC入口/启动？这样当前的应用程序就可以运行，并让另一个应用程序动态地获取应用程序的句柄并利用API

还有其他更有意义的方法吗

[编辑]

---

最终的目标是将业务逻辑分解成一个库，并将GUI分解成某种新的框架（winforms、wpf等等）。现在，我正在寻找从第三方应用程序实现基本API控制的第一个目标的方法。有了这些知识，是否值得做COM接口的中间步骤，然后最终当逻辑被拉入库时，为基本API访问编写.net包装器？

您真正想要的是什么？您是否希望为第三方提供一个API来驱动您的应用程序？或者您真的想用.NET UI替换MFC UI吗

如果是前者，那么答案是COM。COM在.NET中可见，因此如果MFC应用程序支持COM接口，.NET应用程序可以通过它进行调用

我目前正在开发一个MFC应用程序，它完全支持您所描述的内容。我们的EXE公开了一个COM接口，它可以由C++、C语言、VB甚至java编写的其他应用程序驱动。 [根据您的编辑进行编辑]

<>如果你最终想用一个WiFrs/WPF UI替换MFC UI，那么你可以用C++ C++来包住你现有的C++商业代码，并从C语言中访问它。在您的场景中，添加COM API并不是真正的中间步骤。如果你真正想做的是替换UI，那么这需要做很多工作，而且可能不值得

---

您可以参考以阅读我用WPF替换MFC UI的经验的详细信息。

听起来您想将该逻辑放入库中，这可能很棘手，具体取决于您的gui与该逻辑的解耦程度。如果你正在重写，直接考虑C++的库，并将GUI框架的依赖性打开。