【问题标题】:Best way to wrap an MFC Doc/View application in a .NET API?将 MFC Doc/View 应用程序包装在 .NET API 中的最佳方式?
【发布时间】:2011-09-05 14:13:30
【问题描述】:

我目前有一个使用 doc/view 架构的 MFC 项目(松散地)。此应用程序包含所有业务逻辑以及 GUI 代码。我希望提供一种类似 API 的访问方式,可以通过 .NET 访问。在这样做时,我想尽量减少重写,所以我想知道选项是什么?

有没有办法在 MFC 应用程序周围合并一个 .NET 界面,同时仍按原样使用 MFC 入口/启动?以便当前应用程序可以运行并让另一个应用程序动态地获取该应用程序的句柄并使用该 API?

还有其他可能更有意义的方法吗?

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

【问题讨论】:

  • 听起来您想将该逻辑放入库中,这可能会很棘手,具体取决于您的 gui 与该逻辑的分离程度。如果您要进行重写,请考虑为库直接使用 C++,并保持对 GUI 框架的依赖项处于打开状态。

标签: .net c++ mfc


【解决方案1】:

你在这里真正想要什么?您是否想为第三方提供 API 来驱动您的应用程序?或者您真的想用 .NET UI 替换您的 MFC UI?

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

我目前正在开发一个完全支持您所描述内容的 MFC 应用程序。我们的 EXE 公开了一个 COM 接口,它可以由其他用 C++、C#、VB 甚至 Java 编写的应用程序驱动。

[编辑以响应您的编辑]

如果您最终想用 WinForms/WPF UI 替换 MFC UI,那么您可以将现有的 C++ 业务代码包装在 C++/CLI 中并从 C# 访问。在您的场景中,添加 COM API 并不是真正的中间步骤。如果您真正想做的是替换 UI,这需要做很多工作,而且可能不值得。

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

【讨论】:

    猜你喜欢
    • 2019-11-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-22
    • 2014-12-18
    • 1970-01-01
    • 2012-02-28
    相关资源
    最近更新 更多