在COM服務器中使用MFC - 我有什麼選擇？

Question

Visual C++。我必須實現一些繪圖和打印功能，這些功能將被合併到（其他開發人員）的COM DLL中。首先，我想到了使用純GDI做所有事情，除此之外，似乎打印和打印預覽在GDI中完成的工作與MFC實現相比是地獄。所以我決定專注於MFC。這裏快速提出問題：我的選擇正確嗎？我的意思是，在沒有MFC的情況下實現打印（以及打印預覽）有哪些簡單的方法？

現在，我需要MFC（假設如果你也同意這種說法），我對如何做兩個問題：

1）我相信COM DLL是ATL項目（這不是我的代碼，一些其他開發者獨立開發它）。我可以在該dll中啓用MFC支持嗎？在COM服務器中運行MFC運行時有哪些風險/限制/缺點？如果你建議這樣做，我該怎麼做？ 2）儘可能多地影響第三方COM服務器的代碼，我認爲這可能是更好的方法來實現我的代碼作爲一個單獨的基於MFC的DLL，並加載並使用它來自COM服務器的DLL。你是否建議這樣做？這種情況下的風險/限制/缺點是什麼？我想在我的代碼中使用MFC的繪圖，尤其是打印功能，本身應該集成到另一個開發人員的COM DLL（本身用於大型企業應用程序中）。我不是COM技術專家，所以我有點困惑。我最好的選擇是什麼？

Answer 1

你可以在你自己的dll內部使用MFC，並使用非MFC入侵函數向用戶公開功能：例如，如果你需要從/傳遞ypur調用者的一個點，使用GDI標準POINT結構，然後轉換它到一個內部使用的CPoint。在這種情況下，你不需要在ATL項目中引用MFC的使用（這是可能的），但是當然你需要分發或鏈接到MFC DLL。如果你想盡可能保持調用者的COM DLL，你可以創建你自己的ATL + MFC DLL，並通過COM接口暴露你的函數，但保持mynd避免把MFC相關的對象放在界面中。

Answer 2

打印和打印預覽是一個地獄的工作，除非你使用MFC Document/View Architecture。你的COM會暴露這樣的高級UI嗎？

如果你的COM必須獨立於.NET，那麼MFC就是要走的路，否則我會使用.NET。如果您選擇MFC，請確保您靜態鏈接到它。否則，你很可能會在缺少必要的MFC版本的機器上運行時發生錯誤。

除此之外，我不擔心兼容性，因爲COM的概念是讓底層魔術對整數，字符串和其他對象進行編組。