6

Windows サービスの開発を開始しています。CString、CSocket、CArchive、CMemFile、CObject などの一部の MFC クラスにほとんど依存しない、独自のクラスを使用したいと考えています。MSDNは、Windows サービスで使用する MFC の部分について十分に注意する必要があると述べていますが、それを指定したり、発生する可能性のある問題について説明したりしません。

私の質問は次のとおりです。

  • MFC のどの部分を使用できますか?
  • MFC を使用すると、どのような問題が発生する可能性がありますか?
  • Windows サービスのどの部分が MFC の使用に重要ですか?
  • MFC for Windows サービスの代わりに ATL を使用することをお勧めしますか?
4

3 に答える 3

4

MSDN の記事の意味がよくわかりません。GUI 機能を使用しない限りは問題ありませんが、これはサービスを開発する際の一般的な設計上の問題です。

そうは言っても、ATL にはサービス IIRC を構築するために特別に設計された機能があるため、それを使用したほうがよい場合があります。

あなたの質問に答えるには（私の知る限り）：

1) 指定したものは問題ありません。

2) UI コンポーネントとの同期の問題を意味していると思います。CWnd から派生したクラスを使用しない限り、問題ありません。

3) 質問がわかりません。

4) 前を参照してください。さらに、ATL はより軽量であるため、配布する必要が少なくなり、サービスの開発を容易にするビルトイン機能を提供します。例えば ​​CAtlServiceModuleT を参照してください。現在、CString は MFC と ATL の間で共有されており、ATL にはソケット プログラミングとメモリ ファイル マッピング自体のクラスがあるため、ほとんどの場合は独自のクラスを使用できます。CArchive に相当するものはありません。また、CObject で使用する機能がわからないため、ATL に相当するものがあるかどうかはわかりません。結論として、この質問には「はい」と答えたいと思います。

于 2009-07-22T14:54:23.820 に答える
3

（この回答は少し遅れており、この質問はすでに回答されていますが、サービスのMFCは私にとって痛い場所です...）

私が思い出す限り、CSockets には Window が必要です。背景に見えないものを作ります。Windows サービスに既存の MFC コードを含めようとしたときに、これが難しい方法であることがわかりました。これは、ソケット接続を受け入れた場合にのみ必要だったのかもしれません - 思い出せませんか? しかし、うまくいきませんでした！（この制限を理解せずにこれを行うのにどれだけの時間を無駄にしたかは長い話です）

Cオブジェクト? ランタイム クラス ID が必要な場合は、RTTI (dynamic_cast など) を使用します。

CString、私はCStringが好きです。現在ATLと共有されていることは知っていますが、MFCまたはATLを含めずにプルするかどうかはわかりません... std::stringを使用できます。また、誰かが CString と同じメソッドを提供する派生 std::string を作成したことを思い出します。（編集：コードを見つけました-男!!それは過去からの爆発です...）

CArchive、CMemFile: 本当に必要ですか?

とにかく、Roel が言ったように、ATL の方が役立つかもしれません。サーバー側のアプリケーションで MFC を使用することはありません (これまで!) ATL? 多分。COMが必要な場合は、反抗的に。COMはありませんが、CAtlServiceModuleTなどのためです...多分....

于 2009-08-19T19:36:49.570 に答える
0

また、通常の MFC-ATL アプリをサービスに変えようとしているときに経験したサービスでの MFC のもう 1 つの悪い点は、AfxConnectionAdvise() の使用は、ウィンドウ プロシージャなしでは実際には役に立たないことです。私のサービスのスレッドは、通常の非メッセージ ポンピング スレッドです。これが、私が開発した別の COM サーバーからイベントが発生しない理由だと思います。その別の COM サーバーが Fire_xxxEvent() でハングし、システム全体に大きな混乱を引き起こします。

于 2010-03-02T19:31:00.793 に答える