Menu
This probably sounds like a stupid question, but I'm going to give it a shot anyway.
So in Visual Studio, you can't have two projects X and Y such that X references Y and Y references X.
In general, I can totally understand how having a circular dependency can be problematic, for a variety of reasons.
But is it really not possible to compile two projects that are interdependent in this way? It seems to me that it must be possible, since (in my mind -- maybe I'm completely off-base about this) having two mutually dependent assemblies is really not so different from having two mutually dependent classes -- a case which is legal and can be compiled.
It would make sense to me if you said, "two assemblies cannot depend on each other because the compiler could not compile one before the other"; except that it seems you could make the same argument for two classes within the same assembly, and clearly the compiler can deal with this scenario just fine.
Basically the reason I'm asking is not that I have some desperate desire to do this thing that I know is generally ill-advised anyway. Specifically I'm wondering because it would be nice if I could have two projects -- say, MyProjectCS and MyProjectVB -- that existed basically as two mutually dependent parts of a single unit, and were only separate because certain parts were written in C# and other parts were written in VB.NET.
So, my question is (yikes, three-fold):
763
It can happen in Spring when using constructor injection. If we use other types of injections, we shouldn't have this problem since the dependencies will be injected when they are needed and not on the context loading.
Circular dependency problem can be overcome by using interfaces or events. So for the above problem, we can introduce an interface in between the “ MiddleTier ” and “ Dal ”. This interface project you will implement in the middle layer project on the “ Customer ” class.
A circular dependency occurs when two classes depend on each other. For example, class A needs class B, and class B also needs class A. Circular dependencies can arise in Nest between modules and between providers. While circular dependencies should be avoided where possible, you can't always do so.
Circular dependencies also make code difficult to read and maintain over time, which opens the door to error-prone applications that are difficult to test. If circular dependencies proliferate an architecture, any changes to a single module will likely cause a large ripple effect of errors for others.
I don't know how to do it in an IDE; however it is possible to construct via a compilicated build process.
You will need:
where Stub Assembly B contains the public classes and public methods of Assembly B and the same AssemblyInfo.* and references the same public key.
Build order:
Notice that you cannot have direct loop references of the types in the method signatures; however you can have effective loops by casting through object.
NOTE:
ilasm can compile true mutually recursive assemblies as somehow it can resolve types that don't exist at compile time.
FURTHER:
the aspnet_compiler seems to be able to mix different languages in the same project (who knows how).
90
Even though mscorlib.dll and System.dll assemblies are mutually dependent, I'd advise to never have 2 assemblies mutually dependent.
Concerning dependency cycles between hings like namespaces, I'd advise using NDepend to detect and avoid dependency cycles.
Excerpt from the article (I wrote): Control component dependencies to gain clean architecture
Dependency cycles between components lead to what is commonly called spaghetti code or tangled code. If component A depends on B that depends on C that depends on A, the component A can’t be developed and tested independently of B and C. A, B and C form an indivisible unit, a kind of super-component. This super-component has a higher cost than the sum of the cost over A, B and C because of the diseconomy of scale phenomenon (well documented in Software Estimation: Demystifying the Black Art by Steve McConnell). Basically, this holds that the cost of developing an indivisible piece of code increases exponentially.
This suggests that developing and maintaining 1,000 LOC (Lines Of Code) will likely cost three or four times more than developing and maintaining 500 LOC, unless it can be split in two independent lumps of 500 LOC each. Hence the comparison with spaghetti that describes tangled code that can’t be maintained. In order to rationalize architecture, one must ensure that there are no dependency cycles between components, but also check that the size of each component is acceptable (500 to 1000 LOC).
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
