Re: COM... is it the best model so far?
- From: "Alexander Nickolov" <agnickolov@xxxxxxxx>
- Date: Fri, 8 Jun 2007 09:36:56 -0700
COM is not designed for binary reuse. However, nothing
prevents you from using source code reuse as this sidesteps
COM altogether.
BTW, you don't need to know a CLSID of a COM object
in order to use it - you only need its interfaces. A completely
separate piece of code may deal with object instantiation
leaving the rest of your code independent of CLSID
knowledge. In fact, the COM objects you use don't even
need CLSIDs if they are manufactured by other COM
objects.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
<sweetchuck74@xxxxxxxxx> wrote in message
news:1181317318.753573.292750@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Recently, i am examining different component model or framework
deployed in different systems.
What are you people think about the aggreagation or extensibility of
COM?
Even though COM has been successful for many years, IMHO COM is weak
on aggregation or component composition point of view.
For example, creating new component out of existing component
(aggregation) or creating new component from component interactions
(component composition) is hard to do with COM.
There are several component models which seperate the implementation
of component from the usage or composition.
For example,
each component only specifies "required interface" and "provide
interface".
there should be a glue component or container component that are
responsible to instantiate inner components and retrives the
interfaces from them in order to configure or map "required interface"
to "provide interface".
This has several advantages. Consider below cases.
(1) component A need to use interface IB provided by component B. In
COM, component A needs to know CID of component B and IID of interface
IB in order use it. In other words, A is tightly coupled with
component B. In future source code need to be changed if component A
want to use interface IB implemented by component C which exhibits
better performance. If we seperates configuration out of component A,
no source changes are needed on component A. We only need to update
container component. Only dependency component A has is the type of
interface or IID that it requires. It doesn't matter which component
provides this "required interface" since container component figures
out and configures it when instantiating component A.
Such approach also has some drawbacks, particually in dynamic aspect.
Compared with COM, what are the drawbacks of such component model?
.
- Follow-Ups:
- Re: COM... is it the best model so far?
- From: sweetchuck74
- Re: COM... is it the best model so far?
- References:
- COM... is it the best model so far?
- From: sweetchuck74
- COM... is it the best model so far?
- Prev by Date: Re: CFSTR_FILECONTENTS and CFSTR_FILEDESCRIPTOR clipboard formats
- Next by Date: Re: COM... is it the best model so far?
- Previous by thread: COM... is it the best model so far?
- Next by thread: Re: COM... is it the best model so far?
- Index(es):
Relevant Pages
|
