Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Bibliotheken Projektabhängig aufteilen oder nicht
d.jonas
myCSharp.de - Member



Dabei seit:
Beiträge: 21
Herkunft: Bayern

Themenstarter:

Bibliotheken Projektabhängig aufteilen oder nicht

beantworten | zitieren | melden

Hallo miteinander,

mir ist leider keine bessere Überschrift eingefallen; Daher kann diese gerne im Laufe des Gesprächs durch einen Mod. angepasst werden.

Folgende Bibliothekenstruktur habe ich aktuell umgesetzt.

FooApp.Common
FooApp.UI -> benutzt intern ua. AOI.RemoteControl
FooApp.RemoteControl -> TCP ClientServer Bibliothek
FooApp.Server.RemoteControl -> Schnittstellen Server zwischen SPS und FoOApp.UI. Benutzt ua. FooApp.RemoteControl / OPC.FooApp

fertige Anwendung die als Standartprodukt vertrieben wird.

OPC.Alarms -> Schnittstelle zwischen SPS und Suite.Common
OPC.FooApp -> Schnittstelle zwischen SPS und FooApp.Common
OPC.Local -> OPC Client
OPC.AOI -> Schnittstelle zwischen SPS und AOI.Common
OPC.QuellTextGenerator -> Software um SPS auszulesen und daraus Quellen etc. zu generieren
OPC.Leitsystem -> Schnittstelle zwischen SPS und Suite.Common

Suite.Common -> Sämtliche Interfaces und Basisklassen
Suite.ErrorCodes -> Unternehmensweite Deklaration von Fehlercodes. Wird in jeder Anwendung verwendet
Suite.GraphQL.Client -> Benutzt Suite.Common um mit dem Suite.Server zu kommunizieren
Suite.GraphQL.Server -> Benutzt Suite.Common um als Suite.Server zu fungieren und mit dem GraphQL.Client zu kommunizieren
Suite.Local -> Beinhaltet sämtliche Module wie bspw. Alarme, Datenbanken, Benutzerverwaltung, Betriebsdaten, Übersetzungen, Leitsystem
Suite.Server -> Serveranwendung. Benutzt ua. OPC.Alarms, OPC.Leitsystem, OPC.Local, sowie projektabhängig AOI.RemoteControl und/oder FooApp.RemoteControl
Suite.UI.Leitstand -> Anwendung zur Verwaltung des Leitsystems. Benutzt intern den Suite.GraphQL.Client
Suite.UI.Client -> Geführter Werkeranwendung. Benutzt intern den Suite.GraphQL.Client

Aus dem Suite "Softwarepaket" wird für unseren Sonderanlagenbau das Kundenprojekt entwickelt.

AOI.RemoteControl -> TCP Client zur Kommunikation mit einem AOI
AOI.Common -> Schnittstellen
AOI.Server.RemoteControl -> Schnittstellen Server zwischen SPS und AOI. Benutzt ua. AOI.RemoteControl / OPC.AOI
AOI.UI.RemoteControl -> Windows Anwendung zum Fernbedienen des AOI. Benutzt ua. AOI.RemoteControl

Mit der folgenden Struktur bin ich aktuell sehr zufrieden.
Eine spezifische Kundenanwendung lässt sich schnell umsetzen durch das hinzufügen der entsprechenden Bibliotheken. Über die DI werden die Interfaces (*.Common) entsprechend zugewiesen. Sei es nun eine Server oder Clientanwendung.

Als nächsten Schritt würde ich die *.RemoteControl Klassen in ein eigenes Projekt auslagern wollen.

Remote.Common -> Beinhaltet Interfaces für FooApp, AOI usw.
Remote.TCP -> Basis TCP Client
Remote.Serial -> Basis SerialCommunication Client
Remote.AOI -> AOI Client / Server
Remote.FooApp -> FooApp Client / Server

In dem FooApp und dem AOI Projekt müsste ich nur noch die entsprechende Remote.##AppName## Bibliothek einbinden, passendes Protokoll TCP / Serial oder beides hinzufügen und hätte in allen Anwendung den selben Client / Server.

Dabei stellt sich nun die Frage ob es nicht sinnvoller ist, die "Teilprojekte" in die Suite zu packen, da dort in der Regel die komplette Logik vollzogen wird und Debuggen dadurch erheblich einfacher wäre. Konkret meine ich, folgende Projekte

OPC.Alarms
OPC.Leitsystem

werden in das Suite Projekt verschoben:

Suite.OPC -> Beinhaltet OPC.Local bzw. die komplette Logik aus ehemals OPC.Alarms / OPC.Leitsystem

Dadurch würde bei einer Anpassung unseres Suite Projektes (bzw. deren Interfaces) kein erneutes Anpassen der OPC Bibliothek erforderlich. Wenn sich jedoch etwas grundlegendes an der OPC Kommunikation ändert, so müsste man das OPC Projekt aktualisieren und (ggfs.) nur im Kundenprojekt auf die letzte OPC Version gehen.

Dies würde natürlich ebenso für den AOI Teil und dann auch die noch nicht implementierte Remote.* Bibliothek erfolgen.

Ich hoffe mein Problem kann der eine oder andere nachvollziehen und mir einen guten Rat geben wohin ich mit meiner Reise gehen soll bzw. wie man bei so einem Fall am besten seine Projekte aufteilt.

Vielen Dank Vorab!

Gruß
Dominic
private Nachricht | Beiträge des Benutzers
Alf Ator
myCSharp.de - Member



Dabei seit:
Beiträge: 671

beantworten | zitieren | melden

Hallo d.jonas
Zitat von d.jonas
Dabei stellt sich nun die Frage ob es nicht sinnvoller ist, die "Teilprojekte" in die Suite zu packen, da dort in der Regel die komplette Logik vollzogen wird und Debuggen dadurch erheblich einfacher wäre.

Deine Frage lässt sich gar nicht so ohne weiteres Beantworten, merkt man ja auch an der Anzahl der Antworten. xD

Prinzipiell kann ich dir das hier empfehlen: https://langlebige-softwarearchitekturen.de/
Speziell das Stichwort contextmapping
Das hat meinen Horizont sehr erweitert.

Wie das Debugging erleichtert werden soll, habe ich nicht verstanden.

Gruß
Alf
private Nachricht | Beiträge des Benutzers