Board index » delphi » Using a COM tree in a .dll, interfacing with .exe and VCL classes

Using a COM tree in a .dll, interfacing with .exe and VCL classes

I am working on a project where all the business
classes are contained in a .dll as COM components.
These COM components have a hierachical structure,
they are in a tree.

My .exe contains only the user interface.
As part of the interface I want to use the
VCL TTreeView visual component to represent
the hierachical structure of my COM components.
I see two problems with this:

1. The TTreeView and the tree in my business
   layer in the .dll contain exactly the same
   structure, this seems redundant.
2. A tight coupling exists between the tree
   in the .dll and the TTreeView, something
   I would like to avoid.

Does anyone know how to deal with this situation?
Are there any patterns that I might use that
gracefully deal with this problem?
Does anyone have any hints on using trees in COM?

Thank you very much for your time.

--
Stijn
OddesE_...@hotmail.com
http://OddesE.cjb.net
________________________________________________________
Please remove _XYZ from my address when replying by mail

 

Re:Using a COM tree in a .dll, interfacing with .exe and VCL classes


Quote
> 1. The TTreeView and the tree in my business
>    layer in the .dll contain exactly the same
>    structure, this seems redundant.

Well, the content populating the client's Treeview is simply interfaces (to
the COM Objects).  Presumably you request a list of Children to a given
Node's Interface, in order to build your treeview at all.  How you organize
the com objects in the middle tier is of no consequence to the client, since
all it cares about is getting the data it asks for...

Quote
> 2. A tight coupling exists between the tree
>    in the .dll and the TTreeView, something
>    I would like to avoid.

I don't see why it is tightly coupled...  The resemblance of *structures* in
each tier does not mean it is tightly coupled.  If you mean it is tightly
coupled because your are loading the COM DLL into the application's process
space, well that would depend on what you are trying to accomplish with your
overall architecture.  If you have multiple applications consuming the same
info on the same or multiple machines than you could put the Com Objects in
its on Out-of-Proc exe...  If your COM Treeview of COM objects is something
that is reused by various applications over time than the tight coupling is
a minor point, subservient to the overall reason for the COM DLL's
existence...

I'll let somebody else suggest relevant patterns to contemplate.

-dennis

Other Threads