"Tiraman" <ti*****@netvision.net.il> schrieb
First 10x for your answer .
2nd let me describe a little scenario
I have one assemble that handle few function in front of my SQL
and I have one more that handle exceptions and I would like to write
those exceptions in the DB
so as you can see I must work with circular references between those
2 dll's .
example , if there is an error in my Sql dll i call the exception dll
which make
some manipulation and call the sql again in order to write the error
to the DB
I forgot another solution: Put them both in one library.
i did that in VB6 and there was no problem
Mabe you happened to have no problem but I struggled a long time til I
understood that layers of DLLs are a one-way. If once binary compatibility
is broken, you'll run into hell especially with cirular references. Believe
me! How could you set a reference to DLL1? You first must develop DLL1. But
you can't develop DLL1 because it needs DLL2 that is not developped because
it needs DLL1. You see? You're sawing off your own branch if you make
circular references. Whenever it was possible at all, then there is
definitely also another solution that works with 3 DLLs and without circular
references, or with only 1 DLL, or with 2 DLLs also only making a one-way
reference.
so why can't i use or how can i use circular references ?
I wrote the following article in the German group few days ago about the
same problem, so I'm trying to translate (the problem was how to access a
parent form from a usercontrol although the usercontrol and the parentform
were in an EXE and the control in a DLL but both should access each other):
"
I see it this way: A DLL can be accessed from different projects. In the
development process, the DLL is developed first. Because of this, the
developper can not know which projects and classes will be developped later.
Well, he could, if DLL designer and DLL user are the same person or if both
made an agreement, but "compiling technically" this doesn't change anything.
As a principile, a DLL is developped to fulfil some feature requirements.
They are defined and then put into action. Of course the DLL is developped
with the prospect of what it will be used for, but this happens in an
/abstract/ way, not /specifically/, i.e. not relating to certain classes
that do not even exist when the DLL is designed. The layers, consisting of
Exe and n DLLs that are accessing each other, are, concerning the knowledge
of the types a one-way: from top to the bottom.
[...]Another solution are interfaces, i.e. you define them in the DLL and
forces the user to implement them. This ensures the existence of the
members. A different approach is supplying a base class, derived from in
higher layers.
"
What's the best solution in your case, is very individual. Sometimes I'm
even changing my own design again and again til the right structure is
found, so it's hard to find the right one for you.
--
Armin
How to quote and why:
http://www.plig.net/nnq/nquote.html http://www.netmeister.org/news/learn2quote.html