どうも、植田です。
Post by asahiもう少し範囲を絞るとすると、知りたいのはこんなものです。
・ATLをつかったときのプロセスマーシャリングの実装の仕方
1.マーシャリングするための必要条件
2.マーシャリングするために気をつけたほうが良いこと
3.メンバー定義で気をつけたほうが良いこと
4.命名規約 (レジストレーションの仕方などを踏まえて)
「プロセスマーシャリング」という言い回しが不適切なのかも...?
マーシャリングはアパートメントをまたいでオブジェクトにアクセス
する場合に必要となる処理で、典型的にはプロセス間あるいは
マシン間の通信で適用されます。
# パラメータや戻り値などをマーシャリングによって中立的な
# データグラムに変換して転送し、アンマーシャリングによって
# それを元に戻す ― というのが実際の処理です。
表示層のCOMオブジェクト(ActiveXコントロール)と業務層の
COMオブジェクトがどちらもIn-Processサーバー型のCOM
オブジェクトで、同じアパートメントでホストとされているなら、
マーシャリングのことを考える必要はありません。
そうでない場合(たとえば業務層が独立したバックグラウンド
プロセスやサービスとして稼動している場合)であっても、
IDispatchインターフェイスを基底とする、Automation互換の
インターフェイス(dispinterface)の範囲内でインターフェイスを
定義しておけば汎用マーシャラがマーシャリングしてくれるので
余計なものを作らずに済みます。
より効率を求めたり、Automation互換ではないデータ型を扱う
場合にカスタムマーシャリングを実装することになります。
MIDLが自動的に作ってくれるスタブ/プロキシで間に合うなら
それを使ってもいいでしょう。
マーシャリングを完全にコントロールしたい場合はIMarshal
インターフェイスを実装することになりますが、あまり一般的
ではないようです。よほど特殊な事情でもないかぎり、まずは
Automation互換のデータ型だけでインターフェイスを定義
できないかどうか検討したほうが賢明です。
Inter-Object Communication
http://msdn.microsoft.com/en-us/library/ms693719(VS.85).aspx
つまり、マーシャリングのパターンとして次の3つがあり、できる
だけ楽で簡単な方法を選びましょう ― ということです(苦笑)
1. 汎用マーシャラを使った標準マーシャリング
インターフェイスはAutomation互換でなければならない
2. MIDLベースのカスタムマーシャリング
MIDLが生成したスタブ/プロキシを使ったマーシャリング
3. IMarshallインタフェースによるカスタムマーシャリング
すべてを自前で処理するカスタムマーシャリング
命名規則については、結局のところ、バイナリレベルでは
GUID/UUID(CLSIDやIIDなど)やDISPIDを使って識別する
ことになるので、名前そのものに大した意味はなく、一般的
な命名規則と同様、開発者の理解を助けるための約束事
でしかありません。
どんな命名規則であれ、一貫して使うことが肝要です。
.NET Framework General Reference
Naming Guidelines
http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx
.NET Frameworkのドキュメントですけど、ActiveX/COM
にも通用する内容だと思います。
--
植田システム設計事務所
Ueta System Design Studio
http://www.usdesign.jp/
植田真一
mailto:***@usdesign.jp