it-swarm.com.de

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 Serverteil und Clientteil einer App. Ich entwickle meinen eigenen Teil, während mein Freund den zweiten macht. Wir beide sollten jedoch einige gängige Schnittstellen wie User oder AccountInfo oder ChangableAccount... verwenden, um die Kompatibilität sicherzustellen. Wenn ein Client beispielsweise Benutzerdaten an den Server sendet, sollte der Server mit derselben Klasse arbeiten. Das Gleiche 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, besteht darin, ein zusätzliches Projekt zu erstellen, in dem alle gängigen Dinge definiert sind. Wir, ich und mein Freund, sollten dieses Projekt als Abhängigkeit zu einem Hauptprojekt (Client oder Server) hinzufügen. Das gemeinsam genutzte Projekt kann von einem Versionskontrollsystem verwaltet werden, sodass wir immer den aktuellsten Status haben.

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

17
guitar_freak

erstellen Sie ein zusätzliches Projekt, in dem alle gängigen Dinge definiert sind

Dies ist genau der erste Schritt, um wiederverwendbare Teile gemeinsam zu nutzen - 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 Release-Zyklen 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 gleichzeitig.

Wenn letzteres möglich sein soll, benötigen Sie ein striktes Versionsschema und Release-Management für Ihre Bibliothek (und Versionsnummern als Teil des Bibliotheksdateinamens, wie von @RoryHunter vorgeschlagen). In dieser Situation sollten Sie auch auf die Abwärtskompatibilität in Ihrer Bibliothek achten. Ihre Bibliothek sollte als separates Produkt verwaltet werden, indem Sie Unit-Tests hinzufügen, um sicherzustellen, dass die verschiedenen Versionen in der Produktion eine gute Idee sind, und ein Tool wie Maven kann ebenfalls 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. Auf diese Weise kann die gemeinsame Schnittstelle der gemeinsam genutzten Bibliothek viel häufiger als im ersten Szenario geändert werden. Und Sie brauchen nichts wie Maven oder Versionsnummern im Namen der Bibliotheksdatei. Der Nachteil ist jedoch, dass A und B nicht mehr unabhängig voneinander entwickelt werden können.

15
Doc Brown

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. im Debian-Stil;

libmyproject-shared-1.0.jar

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

13
Rory Hunter

erstellen Sie ein zusätzliches Projekt, in dem alle gängigen Dinge definiert sind

Genau so erwartet .Net, dass Sie es tun.

Abstrahieren Sie diese Objekte in eine dritte Assembly und verweisen Sie auf diese aus beiden Projekten. 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/zu deserialisieren (zugegebenermaßen war dies vor während mit Framework 2.0), bestand darin, die "gemeinsam genutzte" Assembly im globalen Assemblycache auf Client und Server zu installieren Maschinen. Wenn die Versammlung für jedes Projekt "lokal" war, sah das Framework sie als diskrete Typen an und weigerte sich, die eine in die andere zu [de] serialisieren.
  • Und das [De] Serialisieren von Objekten, die als Schnittstellen eingegeben werden, ist eine kleine "Herausforderung". Der ursprüngliche Nicht-Schnittstellentyp schien es nicht durch die Serialisierungs-Pipe zu "schaffen", so dass der Empfänger nicht wusste, welchen konkreten Typ er aus dem eingehenden Stream "erstellen" sollte.
2
Phill W.

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

1
BrandonV