Klassen oder Schnittstellen zwischen verschiedenen Projekten teilen

Ich habe nach Antworten in SO oder hier gesucht, aber ohne Ergebnisse, deshalb würde ich Sie fragen.

Nehmen wir an, ich habe zwei verschiedene Projekte - zum Beispiel Server- und Client-Teil einer App. Ich entwickle meinen eigenen Teil, während mein Freund den zweiten macht. Wir beide sollten jedoch einige gemeinsame Schnittstellen wie Useroder AccountInfooder ChangableAccount... verwenden, um Kompatibilität zu gewährleisten. Wenn ein Client beispielsweise Benutzerdaten an den Server sendet, sollte der Server mit derselben Klasse arbeiten. Dasselbe gilt für Schnittstellen usw. Wenn sich Änderungen an einer gemeinsamen Schnittstelle ergeben, sollten beide Projekte ihren Code an die neue Situation anpassen.

Die einzige Lösung, die ich jetzt sehen kann, ist, ein zusätzliches Projekt zu erstellen, in dem alle gemeinsamen Dinge definiert sind. Wir, ich und mein Freund, sollten dieses Projekt als Abhängigkeit zu einem Hauptprojekt (Client oder Server) hinzufügen. Geteiltes Projekt kann von einem Versionskontrollsystem verwaltet werden, so dass wir immer den aktuellsten Stand haben.

Welche andere Lösung würden Sie vorschlagen? Wie werden solche Probleme in professionellen Apps gelöst?

Erstellen Sie ein zusätzliches Projekt, in dem alle gemeinsamen Dinge definiert werden

Dies ist der genau erste Schritt, um wiederverwendbare Teile zu teilen - und es ist der einfache Teil. Der schwierigere Teil besteht darin, zu entscheiden, ob die beiden Projekte, die die gemeinsam genutzte Bibliothek verwenden, unabhängige Veröffentlichungszyklen haben sollen (oder nicht) und ob es möglich sein sollte, dass "Projekt A" Version 1.0 Ihrer gemeinsam genutzten Bibliothek verwendet, während Projekt B verwendet Version 2.0 zur gleichen Zeit .

Wenn Sie möchten, dass Letzteres möglich ist, benötigen Sie ein striktes Versionsschema und eine Versionsverwaltung für Ihre Bibliothek (und Versionsnummern als Teil des Bibliotheksdateinamens, wie von @RoryHunter vorgeschlagen). Sie sollten in dieser Situation auch auf die Abwärtskompatibilität in Ihrer Bibliothek achten. Ihre Bibliothek sollte als separates Produkt verwaltet werden. Fügen Sie Unit-Tests hinzu, um sicherzustellen, dass die verschiedenen Versionen in der Produktion eine gute Idee sind. Auch ein Tool wie Maven kann sinnvoll sein.

Wenn Sie diese Situation jedoch verhindern möchten , sollten Sie "Projekt A", "Projekt B" und Ihre Bibliothek als gemeinsames Projekt mit einem kombinierten Entwicklungs-, Erstellungs- und Freigabeprozess verwalten. Dadurch kann die gemeinsame Schnittstelle der gemeinsam genutzten Bibliothek viel häufiger als im ersten Szenario geändert werden. Und Sie brauchen nicht so etwas wie Maven oder Versionsnummern im Bibliotheksdateinamen. Der Nachteil ist jedoch, dass A und B nicht mehr unabhängig voneinander entwickelt werden können.

Ihre Lösung ist die richtige. Fügen Sie den freigegebenen Code in ein anderes Projekt ein, das eine eigene JAR-Datei erstellt, und verwenden Sie ihn in beiden Projekten. Wenn Sie die JAR-Datei erstellen, möchten Sie möglicherweise die Version in den Namen aufnehmen, z. B. im Debian-Stil.

libmyproject-shared-1.0.jar

Es verhindert keine Probleme mit der Versionierung, sollte aber helfen. Ich habe Maven noch nie benutzt, aber ich verstehe, dass es in dieser Situation helfen kann.

Erstellen Sie ein zusätzliches Projekt, in dem alle gemeinsamen Dinge definiert werden

Genau so erwartet .Net dies von Ihnen.

Ziehe diese Objekte zu einer dritten Versammlung zusammen und beziehe dich dabei auf beide Projekte. Ich würde vorschlagen, dies als Interfaces zu tun, was sauberer ist, aber ...

Achten Sie auf die Serialisierung:

• Die einzige Möglichkeit, Objekte zwischen den beiden Programmen direkt zu serialisieren / deserialisieren (zugegebenermaßen vor einiger Zeit mit Framework 2.0), bestand darin, die "gemeinsam genutzte" Assembly auf Client- und Servermaschinen im globalen Assemblycache zu installieren. Wenn die Assembly für jedes Projekt "lokal" war, sah das Framework sie als diskrete Typen an und lehnte es ab, den einen in den anderen zu [de] serialisieren.
• Das Serialisieren von Objekten, die als Schnittstellen eingegeben wurden, ist eine kleine Herausforderung. Der ursprüngliche Nicht-Schnittstellentyp schien es nicht über die Serialisierungs-Pipe zu schaffen, sodass der Empfänger nicht wusste, welchen konkreten Typ er aus dem eingehenden Stream zu bauen hatte.

Wie andere vorgeschlagen haben, ist Ihr Denkprozess genau. Professionell würden die meisten so etwas wie Maven oder Gradle verwenden , um diese Abhängigkeiten effizient zu verwalten.