Eight lessons from COM (8): The shared object is not easy

xiaoxiao2021-03-06  19

Shared object is not easy

Judging from the message I received and I have asked at the meeting, a problem that many COM programmers who plague many COM programmers is to connect two or more clients to an object instance. To answer this question, it is easy to write a long story (or a booklet), but in fact, as long as it explains the connection with the existing object, it is not easy to automate, it is sufficient. COM provides a large number of ways to create objects, including very popular CoCreateInstance (EX) functions. However, COM lacks a generic naming service that allows the name or GUID to identify the object instance. And it does not provide a built-in way to create an object, then identify it as a call to the interface pointer.

Is this impossible to connect multiple clients with a single object instance? of course not. There are five ways to achieve this. In these resource links, you can find more information or even sample code to guide your operation. Please note that these technologies can not be interchangeable in general; usually, environmental factors will decide which method (if any) is applicable to hand: Singleton object Singleton object is only an object that is only instantiated. There may be 10 clients to call CocreateInstance to "create" Singleton objects, but in fact, they are all receiving interface pointers to the same object. The ATL COM class can be converted to Singleton by adding a Declare_ClassFactory_singleton statement in its class.

File Name Object If an object has implemented IPERSISTFILE, use the file name object in the Run Object (ROT) (which encapsulates the file name of the IPERSISTFILE :: LOAD method of the object), then the client can Use the file name object to connect an existing instance of the object. In fact, the file name object allows the file name to name the object instance, and the object can store their persistence data in these file names. They can even work across the machine.

ComarshalInterface and Counmarshalinterface Save the COM client for the interface pointer to share these interface pointers as long as they are willing to block pointers. COM is willing to provide an optimization of threads to other threads in the same process (see lesson 2), but if the client thread belongs to other processes, Comarshalinterface and CounmarshalinterFace are key ways to implement interface sharing. For discussion and sample code, please refer to MSJ ?? In the July 1999, I am a cool code column.

Custom Class Objects All "Create" COM objects are accompanied by independent objects, called class objects, and their role is an instance of the so-called COM object. Most class objects are implemented in an interface called IClassFactory, including a method of creating an object instance called CreateInstance. (In the underlying, COM converts COCREATEINSTANCE (EX) to call to iClassFactory :: CreateInstance). IclassFactory's problem is that when retrieving interface pointers that point to the previously created object instance, it is not available everywhere. Custom class object is a class object that implements a custom activation interface that replaces the iClassFactory. Since the interface is defined, you can define methods to retrieve references to objects that have been created by this class object. For more information, please refer to the Cool code column in February 1999 in ATL.

Custom Name Object In November 1999, the Cool Code Column introduces a custom name object class that allows the use of C style string named object instance. Pass an instance name to MkParsedisplayName, and you get a name object that is connected to the object instance. One disadvantage of these types of objects is that they cannot work across the Windows NT 4.0. Before using any of these methods Share an object instance between the client: Is it necessary to share? If the method calls from an external data source (database, hardware device, or even global variable) to retrieve data to respond to the client's request, why not assign an object instance for each client, and allow each instance to access the data source? ? You may have to synchronize access to the data source, but do not have to use a custom class object, custom name object, etc. This is how the application constructed by Microsoft Services (MTS), from various reasons, it has proven to be an intellectual programming model, not just the implementation of simple and performance improvement.

转载请注明原文地址:https://www.9cbs.com/read-48069.html

New Post(0)