在.NET API中打包MFC Doc/View應用程序的最佳方法？

我目前有一個使用doc/view架構的MFC項目（鬆散地）。此應用程序包含所有業務邏輯以及GUI代碼。我期望提供一個類似API的訪問權限，可以通過.NET訪問。在這樣做的時候，我想盡量減少重寫，所以我想知道選項是什麼？在.NET API中打包MFC Doc/View應用程序的最佳方法？

有沒有辦法在MFC應用程序周圍加入.NET接口，同時仍然使用MFC入口/啓動程序？因此，當前的應用程序可以運行，並有另一個應用程序動態地獲得應用程序的句柄，並利用API？

其他任何可能更有意義的方法？最終目標是將業務邏輯分解成一個庫和一些新框架的GUI（winforms，wpf，...）。現在，我正在尋找來自第三方應用程序的基本API控制的第一個目標。有了這些知識，值得做一個COM接口的中間步驟，然後最終當邏輯被拉入一個庫，爲基本API訪問編寫一個.net包裝器時呢？

來源

2011-05-31 Jonathan

聽起來像你想把這個邏輯放到一個庫中，這可能是棘手的，取決於你的gui是如何與該邏輯分離的。如果您正在接受重寫，請考慮直接使用C++作爲庫，並將GUI框架的依賴關係保留爲打開狀態。 – AJG85 2011-05-31 15:38:04

你在這裏真的想要什麼？是否要爲第三方提供API來驅動您的應用程序？或者你真的想用.NET UI取代你的MFC UI嗎？

如果是前者，那麼答案是COM。 COM從.NET可見，所以如果您的MFC應用程序支持COM接口，那麼.NET應用程序可以通過它進行調用。

我目前正在使用一個支持你描述的MFC應用程序。我們的EXE公開了一個COM接口，它可以由用C++，C＃，VB甚至Java編寫的其他應用程序驅動。

[編輯迴應你的編輯]

如果你最終要與一個WinForms替換MFC UI/WPF UI，那麼你可以換用C++/CLI和訪問你的現有C++的業務代碼，從C＃。添加一個COM API並不是您的場景中的一箇中間步驟。這是很多工作，如果你真的想要做的是取代用戶界面，可能不值得。

你可以參考this question來閱讀我用WPF替換MFC UI的經驗的細節。

來源

2011-05-31 15:55:49

在.NET API中打包MFC Doc/View應用程序的最佳方法？

回答

相關問題