3,245
社区成员
发帖
与我相关
我的任务
分享IMarshal
什么情况下，组件显示继承IMarshal接口？
我看别人留下的代码，它写的组件继承了IMarshal接口，我不知道这样做有什么意义。
希望各位大侠指点
我看别人留下的代码，它写的组件继承了IMarshal接口，我不知道这样做有什么意义。
希望各位大侠指点
...全文
请发表友善的回复…
发表回复
seasol 2007-01-29
- 打赏
- 举报
一个典型的应用是，对象在跨进程时，实现按值传递。
langzi8818 2007-01-18
- 打赏
- 举报
哎，难道真的没有人吗？？
lxpws 2007-01-18
- 打赏
- 举报
When to Implement
Implement IMarshal only when you believe that you can realize significant optimizations to the COM default implementation. In practice, this will rarely be the case. However, there are occasions, such as the following, where implementing IMarshal may be preferred:
1.The objects you are writing keep their state in shared memory. In this case, both the original process and the client process use proxies that refer to the shared memory. This type of custom marshaling is possible only if the client process is on the same machine as the original process. COM-provided implementations of IStorage and IStream are examples of this type of custom marshaling.
2.The objects you are writing are immutable—that is, their state does not change after creation. Instead of forwarding method calls to the original objects, you simply create copies of those objects in the client process. This technique avoids the cost of switching from one process to another. Some monikers are examples of immutable objects; if you are implementing your own moniker class, you should evaluate the costs and benefits of implementing IMarshal on your moniker objects.
3.Objects that themselves are proxy objects can use custom marshaling to avoid creating proxies to proxies. Instead, the existing proxy can refer new proxies back to the original object. This capability is important for the sake of both efficiency and robustness.
4.Your server application wants to manage how calls are made across the network without affecting the interface exposed to clients. For example, if an end user were making changes to a database record, the server might want to cache the changes until the user has committed them all, at which time the entire transaction would be forwarded in a single packet. Using a custom proxy would enable the caching and batching of changes in this way.
Implement IMarshal only when you believe that you can realize significant optimizations to the COM default implementation. In practice, this will rarely be the case. However, there are occasions, such as the following, where implementing IMarshal may be preferred:
1.The objects you are writing keep their state in shared memory. In this case, both the original process and the client process use proxies that refer to the shared memory. This type of custom marshaling is possible only if the client process is on the same machine as the original process. COM-provided implementations of IStorage and IStream are examples of this type of custom marshaling.
2.The objects you are writing are immutable—that is, their state does not change after creation. Instead of forwarding method calls to the original objects, you simply create copies of those objects in the client process. This technique avoids the cost of switching from one process to another. Some monikers are examples of immutable objects; if you are implementing your own moniker class, you should evaluate the costs and benefits of implementing IMarshal on your moniker objects.
3.Objects that themselves are proxy objects can use custom marshaling to avoid creating proxies to proxies. Instead, the existing proxy can refer new proxies back to the original object. This capability is important for the sake of both efficiency and robustness.
4.Your server application wants to manage how calls are made across the network without affecting the interface exposed to clients. For example, if an end user were making changes to a database record, the server might want to cache the changes until the user has committed them all, at which time the entire transaction would be forwarded in a single packet. Using a custom proxy would enable the caching and batching of changes in this way.
