'Circular dependencies
I have 2 projects.
Project#2 has a reference to Project#1
Now I need to reference Project#2 in Project#1, but vs.net is complaining about a circular dependency.
Is there a way out of this?
Solution 1:[1]
Refactor your projects to take the common elements out into a "Project #0" which both Project #1 and Project #2 reference.
Solution 2:[2]
Merge the two into one or redesign.
Solution 3:[3]
This points to a problem in your design. If there is a genuine need for two or more of your types to be mutually aware then they should exist in the same assembly.
Solution 4:[4]
No. Structure your projects properly. Try using some sort of ordering based on abstraction - low-level to high-level.
Solution 5:[5]
A circular dependency means that these are no longer two independent projects (because there it is impossible to build only one of them).
You need to either refactor so that you have only a one way dependency or you should merge them into a single project.
Solution 6:[6]
Circular reference can be done as seen in a previous question, but you should not do it for the reasons everybody already stated here.
Solution 7:[7]
I really don't mean to be a smart-aleck, but better program design is the answer.
Solution 8:[8]
Everyone will tell you this is a bad design do not do it etc. However sometimes it is easier said than done and moving the implementation into a separate common code is not desirable. For such cases instead of calling the other package directly, emit an event from one package and handle it in the other. That way you do no need to make the other component a dependency in the first component.
Another way if you still want to keep the implementation in separate packages is to derive your logic classes form interfaces and define those in a separate package. This works if you have a way to instantiate the implementation, for example via dependency injection or other means.
Solution 9:[9]
This seems to be a design flaw, nothing else. Re-design is the solution.
Solution 10:[10]
Contrary to what's been said before, circular dependencies are sometimes unavoidable. For sure there are benefits to linear designs (maintainability, readability, debugging etc.) but it makes no sense to give up circularity/bidirectionality if it is going to make you give up on splitting projects based on their functionality (which wouldn't help you maintain or understand the code).
Solution: You have to use a project with interfaces to which both of said projects reference to. Classes from higher level projects contain implement interfaces from the interface project. This way you can expose method implementations and classes in a circular manner.
Some pseudocode:
Project Interface
interface IApple { void dropOnHead(IPerson person);}
interface IPerson { void eatApple(IApple apple);}
Project#1
using ProjectInterfaces;
class Apple : IApple{
void dropOnHead(IPerson person) { log("bop");}
}
Project#2
using ProjectInterfaces;
class Person : IPerson{
void dropOnHead(IApple apple) { log("crunch");}
}
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow