Implications of circular references.

[Frank Rizzo]

I have a circular reference between 2 classes in the same project (i.e.
each class refers to the other). The app runs fine and I am seeing no
issues, which kind of surprised me.

Are there any issues that I am not seeing (performance wise or garbage
collection wise) with circular references?

Thanks.

 

[Bruce Wood]

The only circular reference issues I know of in .NET are between
assemblies. .NET doesn't allow classes in different assemblies to
mutually reference each other.

Other than that, no problem.

 

[Steve Walker]

I have a circular reference between 2 classes in the same project (i.e.
each class refers to the other). The app runs fine and I am seeing no
issues, which kind of surprised me.

Are there any issues that I am not seeing (performance wise or garbage
collection wise) with circular references?

Getting round the circular references problem is one of the benefits of
the garbage collection algorithm .NET uses over a reference counting
scheme. If neither object is reachable, they're both available to be
GC'd.

 

[Frank Rizzo]

The only circular reference issues I know of in .NET are between
assemblies. .NET doesn't allow classes in different assemblies to
mutually reference each other.

Other than that, no problem.

I know about the fact that you can't do circular refs between
assemblies. What I am wondering is whether I'll have (possibly
difficult to troubleshoot) issues if there are circular refs between
objects in a single assembly.

 

[Richard Blewett [DevelopMentor]]

They also come crashing in in COM interop. If I have a reference to a COM object via an RCW and I hand a refernce to myself to it (so it gets a CCW) we have a reference counted/live rooted deadly embrace

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

The only circular reference issues I know of in .NET are between
assemblies. .NET doesn't allow classes in different assemblies to
mutually reference each other.

Other than that, no problem.

 

[Bruce Wood]

None that I know of, other than it points out a possible place in your
design where you could use interfaces to do some abstraction.

I have circular references between my business layer and my data layer.
(My business layer is the "outer face" of the two layers, and so has to
know how to call the data layer. The data layer returns and consumes
business objects.)

It hasn't caused me any runtime / practical problems. My only regret is
that reading posts by Joanna Carter here I'm beginning to realize that
I should create an abstract data layer interface and have the business
layer call that instead, so that it doesn't have to know about the data
layer directly.

As I said, though, that's an OO design thing. As for practical
gotchas... none so far.

 

[John B]

The only circular reference issues I know of in .NET are between
assemblies. .NET doesn't allow classes in different assemblies to
mutually reference each other.

Actually, it does.
c# handles it fine so long as you dont lose the binaries.
vb.net spits it.
(not that I'm advocating it in any way)
JB

 

[Bruce Wood]

Actually, it doesn't, at least not within the same project. It's a
problem of which to compile first. Since the compiler gets its class /
interface / method signature information from the compiled assembly, it
can't compile assembly A, which references assembly B, without first
compiling B so that it can check A's references to things in B to
ensure that they're valid references. However, it can't compile B until
it first compiles A so that it can check B's references to things in A
to ensure that they're valid references.

Unfortunately, the compiler doesn't say anything like "circular
assembly reference". Instead it just throws up its (virtual) hands and
says that (if it chose to compile A first) it "can't find" any of the
things in assembly B.

I've never tried putting the circular-referencing assemblies in
different projects, and compiling one (without the circular reference),
then the other, then adding the circular reference and compiling the
first project again. In theory the compiler wouldn't notice, but as I
said, I've never tried it.

 

[Richard Blewett [DevelopMentor]]

Visual Studio doesn't like circular project references but the C# compiler is quite happy with circular assembly references

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Actually, it doesn't, at least not within the same project. It's a
problem of which to compile first. Since the compiler gets its class /
interface / method signature information from the compiled assembly, it
can't compile assembly A, which references assembly B, without first
compiling B so that it can check A's references to things in B to
ensure that they're valid references. However, it can't compile B until
it first compiles A so that it can check B's references to things in A
to ensure that they're valid references.

Unfortunately, the compiler doesn't say anything like "circular
assembly reference". Instead it just throws up its (virtual) hands and
says that (if it chose to compile A first) it "can't find" any of the
things in assembly B.

I've never tried putting the circular-referencing assemblies in
different projects, and compiling one (without the circular reference),
then the other, then adding the circular reference and compiling the
first project again. In theory the compiler wouldn't notice, but as I
said, I've never tried it.

 

[Michael S]

None that I know of, other than it points out a possible place in your
design where you could use interfaces to do some abstraction.

I have circular references between my business layer and my data layer.
(My business layer is the "outer face" of the two layers, and so has to
know how to call the data layer. The data layer returns and consumes
business objects.)

It hasn't caused me any runtime / practical problems. My only regret is
that reading posts by Joanna Carter here I'm beginning to realize that
I should create an abstract data layer interface and have the business
layer call that instead, so that it doesn't have to know about the data
layer directly.

As I said, though, that's an OO design thing. As for practical
gotchas... none so far.

If you want more Bruce, our dear Joanna Carter, can easily be found on
borlands newsgroups, especially the oo-design group.

- Michael S

 

[Michael S]

In message <[email protected]>, Frank Rizzo
Getting round the circular references problem is one of the benefits of
the garbage collection algorithm .NET uses over a reference counting
scheme. If neither object is reachable, they're both available to be GC'd.

Frank, with other words:

The GC will start by assuming that all objects are dead.
Then it starts traversing all object references, starting by the application
root and all object references on the stack.

Hence, if your circular objects cannot be reached, they have allready been
concidered dead and will be collected.

Happy Coding
- Michael S

 

[Joanna Carter \(TeamB\)]

None that I know of, other than it points out a possible place in your
design where you could use interfaces to do some abstraction.

Certainly, circular references are a good indicator that it is time to
refactor

It hasn't caused me any runtime / practical problems. My only regret is
that reading posts by Joanna Carter here I'm beginning to realize that
I should create an abstract data layer interface and have the business
layer call that instead, so that it doesn't have to know about the data
layer directly.

As long as you have sufficient metadata available in your business objects,
there should be absolutely no need for the data layer to know about specific
business classes.

In my OPF, I use a generic SQL generation mechanism for storing/retrieving
instances of most classes, but if a class should prove difficult/slow
(reporting classes that contain many joins), I construct a custom
persistence handler for that class that has intimate knowledge of the class
and of the type of persistence connection behind the OPF. Use of a Mediator
class like this resolves the circular problem.

Joanna

 

[John B]

Actually, it doesn't,

Yes, it does.

at least not within the same project.

Within the same project it is definitely possible.
Within different projects, within the same solution, VS wont let you add
the reference, so it will not allow it.

It's a
problem of which to compile first. Since the compiler gets its class /
interface / method signature information from the compiled assembly, it
can't compile assembly A, which references assembly B, without first
compiling B so that it can check A's references to things in B to
ensure that they're valid references. However, it can't compile B until
it first compiles A so that it can check B's references to things in A
to ensure that they're valid references.

Unfortunately, the compiler doesn't say anything like "circular
assembly reference". Instead it just throws up its (virtual) hands and
says that (if it chose to compile A first) it "can't find" any of the
things in assembly B.

I've never tried putting the circular-referencing assemblies in
different projects, and compiling one (without the circular reference),
then the other, then adding the circular reference and compiling the
first project again. In theory the compiler wouldn't notice, but as I
said, I've never tried it.

Yes, this works.
I should have specified MS VS .NET though.


JB