如果我做网站使用的COM是不是应该选择Dynamic DLL,而不是 EXE 和SERVICE
ATL COM中 什么时候使用support MTS选项?这样做有什么好处和弊端当我新建一个ATL COM项目,并仅仅选择Dynamic DLL 和 SUPPORT MFC的时候
INSERT ATL OBJECT的时候 :选择Category中的Objects的时候,右边的Simple Object, 
Add-in Object ,Internet Explorer Object,ActiveX Server Component, MMC Snapln,
MS Transation Server,Component Registrar Object应该选择哪个呢?这些接口在编程的时候有什么不同?我实验了一下,选择
Simple Object和ActiveX Server Component的时候我向其中添加完全相同的接口,从asp页面中调用的时候效果完全相同,如果我只是想用其写一个组件供asp页面调用, 在这个组件中实现
对数据库的操作,那么我应该选择哪个选项才能保证功能实现并且效率和稳定性相对高一些?当insert ATL Object的时候在选项页中的Attributes页中的三个选项Threading Model,Interface,
Aggregation都是什么意思啊,我应该选择哪个呢?

解决方案 »

  1.   

    如果我做网站使用的COM应该选择Dynamic DLL   support MTSActiveX Server Component
      

  2.   

    3.Threading Model 表示选择线程模型
    Objects created in a single-threaded apartment (STA) receive method calls only from their apartment's thread, so calls are serialized and arrive only at message-queue boundaries (when the Win32 function PeekMessage or SendMessage is called).Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time. You would typically implement some form of concurrency control in a multithreaded object's code using Win32 synchronization primitives such as critical sections, semaphores, or mutexes to help protect the object's data. When an object that is configured to run in the neutral threaded apartment (NTA) is called by a thread that is in either an STA or the MTA, that thread transfers to the NTA. If this thread subsequently calls CoInitializeEx, the call fails and returns RPC_E_CHANGED_MODE.When a thread is initialized through a call to CoInitializeEx, you choose whether to initialize it as apartment-threaded or multi-threaded by designating one of the members of COINIT as its second parameter. This designates how incoming calls to any object created by that thread are handled, that is, the object's concurrency.Apartment-threading, while allowing for multiple threads of execution, serializes all incoming calls by requiring that calls to methods of objects created by this thread always run on the same thread – the apartment/thread that created them. In addition, calls can arrive only at message-queue boundaries (i.e., only during a PeekMessage, SendMessage, DispatchMessage, etc.). Because of this serialization, it is not typically necessary to write concurrency control into the code for the object, other than to avoid calls to PeekMessage and SendMessage during processing that must not be interrupted by other method invocations or calls to other objects in the same apartment/thread.Multi-threading (also called free-threading) allows calls to methods of objects created by this thread to be run on any thread. There is no serialization of calls – many calls may occur to the same method or to the same object or simultaneously. Multi-threaded object concurrency offers the highest performance and takes the best advantage of multi-processor hardware for cross-thread, cross-process, and cross-machine calling, since calls to objects are not serialized in any way. This means, however, that the code for objects must enforce its own concurrency model, typically through the use of Win32 synchronization primitives, such as critical sections, semaphores, or mutexes. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in Thread-Local-Storage). 
      

  3.   

    ThreadModle表示选择线程模型
    Objects created in a single-threaded apartment (STA) receive method calls only from their apartment's thread, so calls are serialized and arrive only at message-queue boundaries (when the Win32 function PeekMessage or SendMessage is called).Objects created on a COM thread in a multithread apartment (MTA) must be able to receive method calls from other threads at any time. You would typically implement some form of concurrency control in a multithreaded object's code using Win32 synchronization primitives such as critical sections, semaphores, or mutexes to help protect the object's data. When an object that is configured to run in the neutral threaded apartment (NTA) is called by a thread that is in either an STA or the MTA, that thread transfers to the NTA. If this thread subsequently calls CoInitializeEx, the call fails and returns RPC_E_CHANGED_MODE.
    When a thread is initialized through a call to CoInitializeEx, you choose whether to initialize it as apartment-threaded or multi-threaded by designating one of the members of COINIT as its second parameter. This designates how incoming calls to any object created by that thread are handled, that is, the object's concurrency.Apartment-threading, while allowing for multiple threads of execution, serializes all incoming calls by requiring that calls to methods of objects created by this thread always run on the same thread – the apartment/thread that created them. In addition, calls can arrive only at message-queue boundaries (i.e., only during a PeekMessage, SendMessage, DispatchMessage, etc.). Because of this serialization, it is not typically necessary to write concurrency control into the code for the object, other than to avoid calls to PeekMessage and SendMessage during processing that must not be interrupted by other method invocations or calls to other objects in the same apartment/thread.Multi-threading (also called free-threading) allows calls to methods of objects created by this thread to be run on any thread. There is no serialization of calls – many calls may occur to the same method or to the same object or simultaneously. Multi-threaded object concurrency offers the highest performance and takes the best advantage of multi-processor hardware for cross-thread, cross-process, and cross-machine calling, since calls to objects are not serialized in any way. This means, however, that the code for objects must enforce its own concurrency model, typically through the use of Win32 synchronization primitives, such as critical sections, semaphores, or mutexes. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in Thread-Local-Storage). 
      

  4.   

    Dynamic DLL 不要SUPPORT MFCSimple Object就可以了。其它默认就可以了。
      

  5.   

    Interface 选择接口类型,建议选择Custom,从IUnknown接口派生COM接口dual 从IDispatch接口派生服务器内部的接口
      

  6.   

    the class allows its interfaces to be exposed by a container class as if these interfaces were the container's own interfacesno 表示不能yes The COM object can be created directly or it can be aggregated. This is the defaultonly The COM object cannot be created directly and can only be aggregated. When you call CoCreateInstance for this object, you must specify the aggregating object's IUnknown interface (the controlling IUnknown).
      

  7.   

    support MTS 使得你的 DLL 支持微软事务服务器
    你的应用应当选择 simple object, 因为你只是从页面调用这个组件,而无需组件关联到页面线程模式决定了对象引用和释放时的线程安全性
    接口类型一般使用 dual, 这个你应该参考关于 IDispatch 的内容
    Aggregation 指定对象能否被聚合
      

  8.   

    选择SUPPORT MTS 然后注册成COM+组件服务器,就可以满足你的并发要求了。
    在COM+的安全设置当中设置各种使用权限就可以达到你的要求。
    不需要加代码。