Circular Reference Hell!
-
Hi, I am trying to use a class in multiple projects. It is a simple class containing properties of a given database table. The class, DbTable, is defined in my main DbCompare project. I also want to use this class in a Control Library (UserControl) project which will itself be used in the DbCompare project. However, I am in circular reference hell! When I build the DbCompare project, I get the warning 'DbCompare.DbTable' is defined in multiple places; using definition from 'D:\Proj_net\DbCompare\DbTable.cs'. Does anyone know how to do this? TIA, Royce
-
Hi, I am trying to use a class in multiple projects. It is a simple class containing properties of a given database table. The class, DbTable, is defined in my main DbCompare project. I also want to use this class in a Control Library (UserControl) project which will itself be used in the DbCompare project. However, I am in circular reference hell! When I build the DbCompare project, I get the warning 'DbCompare.DbTable' is defined in multiple places; using definition from 'D:\Proj_net\DbCompare\DbTable.cs'. Does anyone know how to do this? TIA, Royce
If you can re-architect your application I would suggest using events to avoid the circular references. If you have a layered approach like this:
Presentation ---------------- Business Logic ---------------- Data AbstractionThe Presentation can invoke methods directly in the Business Logic layer, and the Business Logic layer can do the same to the Data Abstraction layer. However the Data Abstraction layer should know nothing of the Business Logic layer, and the Business Logic layer should know nothing of the Presentation layer. Think about how the .NET Framework achieves this. The guys at Microsoft know nothing of your application, so the controls fire off events in order to pass messages to your code. So, If the Data Abstraction layer needs to invoke something in the Business Logic layer it should fire off an event that something in the Business Logic layer subscribes to. Similarly with the Business Logic layer needing to invoke something in the Presentation layer. Does this help?
-
If you can re-architect your application I would suggest using events to avoid the circular references. If you have a layered approach like this:
Presentation ---------------- Business Logic ---------------- Data AbstractionThe Presentation can invoke methods directly in the Business Logic layer, and the Business Logic layer can do the same to the Data Abstraction layer. However the Data Abstraction layer should know nothing of the Business Logic layer, and the Business Logic layer should know nothing of the Presentation layer. Think about how the .NET Framework achieves this. The guys at Microsoft know nothing of your application, so the controls fire off events in order to pass messages to your code. So, If the Data Abstraction layer needs to invoke something in the Business Logic layer it should fire off an event that something in the Business Logic layer subscribes to. Similarly with the Business Logic layer needing to invoke something in the Presentation layer. Does this help?