Laden...

Projekt trotz Ringabhängigkeiten compilieren bzw. Ringabhängigkeiten vermeiden

Erstellt von Bix vor 17 Jahren Letzter Beitrag vor 16 Jahren 6.929 Views
B
Bix Themenstarter:in
9 Beiträge seit 2006
vor 17 Jahren
Projekt trotz Ringabhängigkeiten compilieren bzw. Ringabhängigkeiten vermeiden

Hallo alle zusammen!

Ich habe vor ein Projekt von mir, welches mittlerweile sehr groß geworden ist, in mehrere Teilprojekte aufzuspalten.

Es geht dabei um eine Serveranwendung.

Mein Code sieht vom Prinzip her so aus (stark vereinfacht):

Server.cs
Soll zur ausführbaren Datei werden und mit TPC-Paketen aus den unten stehenden DLLs arbeiten:


namespace Server
{
	public class Server
	{
		public static void Main()
		{
			// ...
		}
	}

	public class Connection
	{
		// Einige Methoden
	}
	
	public class Modell
	{
		// Modell welches von den Clients verändert wird
	}
}

PacketsClient.cs (soll eine eigene DLL werden)


namespace Packets.Client
{
	public abstract class ClientPacketBase
	{
		public static ClientPacketBase ParsePacket(byte[] rawData)
		
		protected byte[] rawPacketData;
		public abstract void ProcessPacket();
	}
	
	public class ClientBlabla
	{
		public void ProcessPacket()
		{
			// Verarbeite das Paket und ändere das Modell dementsprechen
			Server.Modell.ErhoeheWert(x);
			
			// Sende eventuell ServerPackets an den Client als Bestätigung
			Server.Connection.Send(new ServerPacketX(parameter));
		}
	}
}

PacketsServer.cs (soll ebenfalls eine eigene DLL werden)


namespace Packets.Server
{
	public abstract class ServerPacketBase
	{
		public abstract byte[] GetRawData();
	}
	
	public class ServerPacketX
	{
		public ServerPacketX(int parameter)
		{
			// ...
			// verändere noch etwas im Modell
			Server.Modell.GesendetePaketeGesamt++;
		}
		
		public byte[] GetRawData()
		{
			// ...
		}
	}
}

Jetzt habe ich in meiner Solution in Visual Studio 2005 3 Projekte erstellt. Server, PacketsClient und PacketsServer. Jetzt haben ja aus den Anforderungen heraus die einzelnen Projekte folgende Abhängigkeiten:

Server:

  • Benötigt Packets.Server um Serverpakete wegschicken zu können.

PacketsClient:

  • Benötigt Zugriff auf Klassen aus dem Namespace Server um das Modell verändern zu können

  • Benötigt Zugriff auf Klassen aus dem Namespace Packets.Server um Meldungen an die Clients zu verschicken

Packets.Server:

  • Benötigt Zugriff auf den Namespace Server um auf das Modell zuzugreifen

Leider gibt es jetzt zwischen Server und Packets.Server eine Ringabhängigkeit. 🙁

Gibt es eine Möglichkeit dem Compiler beizubringen, dass er das so machen soll wie ich es möchte?

Viele Grüße,
Bix

1.271 Beiträge seit 2005
vor 17 Jahren

Hallo Bix,

Sowas kannst du dem Compiler nicht beibringen (eigentlich müsstest du das eh VS beibringen). Es ist nicht möglich sowas zu kompilieren:
A ist abhängig von B, B von C und C wieder von A. Wo würdest du anfangen zu kompilieren? Genau, du hast keine Ahnung. Du musst versuchen die Abhängigkeiten irgendwie aufzulösen, tüftel am besten mal ein bisschen rum.

Gruß,
Thomas

A wise man can learn more from a foolish question than a fool can learn from a wise answer!
Bruce Lee

Populanten von Domizilen mit fragiler, transparenter Außenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.

D
128 Beiträge seit 2005
vor 17 Jahren

Hi!

Ich kann nur Progger beipflichten und sagen, dass bei einer Ringabhaengigkeit meistens ein UML-Diagram hilft diese direkt im Voraus zu erkennen und zu vermeiden. Momentan ist das Projekt auf "nur" 3 Projekte beschraenkt, kann aber trotzdem helfen sich einen Ueberblick ueber die Abhaengigkeiten zu verschaffen und entsprechend das Design anzupassen.

Gruss, DaMoe

B
Bix Themenstarter:in
9 Beiträge seit 2006
vor 17 Jahren

Ich habe es mittlerweile auch eingesehen, dass es nicht geht. Habe vielleicht auch etwas voreilig gefragt. Ich bin jetzt zu dem entschluss gekommen, dass ich die Objekte aus dem Modell auf die ich über meine Pakete zugreifen muss mit Interfaces versehe und diese Interfaces dann in beiden Assemblies (Modell und Packets.Server/Client) zu finden sein werden. Ich denke so müsste es klappen. 🙂

EDIT:
Ich habe nun Interfaces für den Zugriff auf mein Modell definiert. Jetzt funzt es.
Danke nochmal an euch für die fixen Antworten 🙂

193 Beiträge seit 2005
vor 16 Jahren

*rauskram*

Also ich habe jetzt ein Ähnliches Problem, A auf B und B auf A. Das das nicht geht ist klar uns sehe ich ein. Ich brauch jetzt trotzdem eine Lösung dazu, da ich diese Abhängigkeiten voneinenader benötige bzw. genauer gesagt die Methoden des anderen Projekts braucht das eine.

Wie kriegt man das anders hin?

Hintergrund ist der:
Ich habe ein Netzwerkmodul und ein Workmodul. Normalerweise greift das Netzwerkmodul immer auf der Workmodul zu. Nun hab ich aber einen einzigen Spezialfall, wo das Workmodul vom anderen Client eine weitere Information zum weiterarbeiten benötigt.

Also sieht das visuell so aus:
Client 1: Netzwerkmodul => Client 2: Netzwerkmoduel => Client 2: Workmodul, braucht weitere Infos => Client 2: NM => Client 1: NM => und wieder zurück halt.

Gibs ne Lösung oder andere Art und Weise das umzusetzten?

Visit me @ www.beremote.net

49.485 Beiträge seit 2005
vor 16 Jahren

Hallo Hunv,

eigene Events könnten da passend sein oder auch direkt ein Delegat/Callback. Damit kannst du auf jeden Fall die Abhängigkeit aufbrechen. Das WorkerModul feuert einen eigene Event, wenn es die Informationen benötigt und das NetzwerkModul füllt die Informationen in die von dir definiere EventArgs-Klasse.

herbivore

193 Beiträge seit 2005
vor 16 Jahren

und wie kriegt das workmodul vom networkmodul die daten?

mal oberflächlich gesehen kennt das workmodul das networkmodul nicht - nur umgekehrt, oder verstehe ich da was falsch?

Visit me @ www.beremote.net

49.485 Beiträge seit 2005
vor 16 Jahren

Hallo Hunv,

und wie kriegt das workmodul vom networkmodul die daten?

wie ich schon schrieb über die eigene EventArgs-Klasse.

mal oberflächlich gesehen kennt das workmodul das networkmodul nicht - nur umgekehrt

Richtig! Das meinte ich mit "die Abhängigkeit aufbrechen".

herbivore