Architektur, Fachliche oder Technische Trennung

[eskimo328]

was für eine Package-Struktur schlagt ihr für eine Swing-Anwendung mit Datenbankanbindung vor? Als Beispiel, die Anwendung bietet eine Auftragserfassung, Kundenverwaltung, mehrere Statistiken, Internationalisierung, kundenspezifische Einstellungen und Verarbeitungen, Generierung PDFs, Excel-Export, Anbindung an ERP-System, ...

Beispiel 1: 
+ dao
   - KundenDAO
   - AufträgeDAO
   - StatistikDAO
+ ui.swing
   - kundenverwaltung
   - auftragserfassung
   - statistik
+ business logic
   - kundenverwaltung
   - auftragserfassung
   - statistik
+ core
   - update
   - erp-anbindung
   - dbconnection
+ kundenspezifische Einstellungen
+ resources
   - img
   - labels

Beispiel 2: 
+ kunden
    - KundeDAO
    - business logic
    - ui.swing
+ statistik
    - StatistikDAO    
    - business logic
    - ui.swing
+ core
   - update
   - erp-anbindung
   - dbconnection
+ kundenspezifische Einstellungen
+ resources
   - img
   - labels

Oder würdet ihr komplettt anders aufteilen?

 

[maki]

Kommt auf deine Architektur an

 

[KrokoDiehl]

Interessantes Thema. Ich freue mich auch schon auf die Antworten
Mit Sicherheit kann man hierzu sagen: Kommt drauf an (...und man hat Recht)!
Dennoch lasse ich es mir nicht nehmen, meine Meinung mitzuteilen

Zu der genannten Architektur würde eher in Richtung Beispiel 2 tendieren, denn...

Ihr habt separate Anwendungsteile, die ich in separate Pakete stecken würde. Allein schon um spätere Suchen, Erweiterungen, Austausche usw. zu erleichtern. Die jeweilige Substruktur würde ich dann aber sehr ähnlich halten, damit ein durchgängiges Konzept erkennbar bleibt (s. mein Beispiel).

Aber unbedingt würde ich auch ein allgemeines Paket definieren, in dem alle anwendungsübergreifenden Implementierungen zu finden sind. Gerade etwas wie Datenbankanbindung, Fehlerbehandlung, Rechte- und Einstellungsverwaltung (uvm) sollte einheitlich und allgemein gemacht werden.

Letztlich komme ich auf einen folgenden Vorschlag:

Anwendung
 + Statistiken
      - gui
      - core
 + Auftragserfassung
      - gui
      - core
 + Kundenverwaltung
      - gui
      - core
 + (Teilanwendung x)
      - ...
 + Allgemeines
      - Datenbankveraltung
      - Fehlerbehandlung
      - Rechteverwaltung
      - ...
 + Resourcen
      - Grafiken
      - Texte
      - ...

Die Namen sind natürlich flexibel. Auch wie man die Subpakete gestaltet ist bestimmt abhängig davon, wie der Anwendungsteil aussieht. Aber gerade bei GUI-Anwendungen bietet sich eine MVC bzw. gui/core-Aufteilung an.

Was deine übrigen Programmteile (ERP-Anbindung, PDF, Excel, ...) anbelangt, kommt es wohl darauf an, wie allgemein sie sind. Kann theo. jeder Anwendungsteil einen Excel-Export durchführen? Dann sollte es ins allgemeine Paket.

Natürlich muss man sich auch Gedanken darüber machen, inwieweit die Anwendungsteile untereinander zusammenhängen. Dies kann die Struktur auch beeinflussen. Vor allem es ein großes JAR wird, oder jeder Teil auch separat ausführbar (& auslieferbar) sein soll wird hier auch eine Rolle spielen

 

[maki]

Die GUI/Core Aufteilung hat nix mit MVC zu tun.
IMHO macht es keinen Sinn, so eine Struktur zu verwenden:

Anwendung
 + Statistiken
      - gui
      - core
 + Auftragserfassung
      - gui
      - core
 + Kundenverwaltung
      - gui
      - core
      - ...

.. wenn man kein Modul-/Pluginsystem wie zB. OSGi und/oder Eclipse RCP nutzt.

Das man MVC/MVP einsetzen sollte ist eine gute Idee, aber das betrifft ja nur die GUI Schicht, was "dahinter" kommt sollte auch noch Strukturiert werden, entweder als "klassiches" Schichtenmodell, welches dann zwangsweise die technische Infrastruktur widerspiegelt (GUI-Logik-Persistenz), oder als Zwiebelmodel, welches dann die fachlichen Aspekte widergibt, und die technische Infrastruktur "verbirgt".

 

[KSG9|sebastian]

Na ja, ich würd mal sagen das bei beiden Varianten die Wahl zwischen Not und Elend besteht.

Solch eine Anwendung mit so vielen Funktionen unterteilt man nicht mit Packages sondern mit Projekten.

Ich würde mal folgendes Vorschlagen:

- für jede fachliche Funktion (Statistiken, Kundenerfassung, Auftragsverwaltung) ein separates Projekt
- ein Projekt für häufig genutzte Dinge (Utilities u.s.w.)

- Basisprojekte:
1. GUI-Teile -> stellt Funktionen bereit um fachliche Komponenten zu bauen, z.B. einen Rumpf für die Anwendung
2. Core/Service-Teile -> Komponenten um mit dem Servicelayer zu kommunizieren (falls es einen gibt)
3. Datenbank-Teile -> Abstraktionen für Datenbankzugriffe

 

[eskimo328]

für jede fachliche Funktion ein Package wäre zu überdimensioniert.
Beispiel kundenverwaltung:
- Es gibt lediglich eine Maske mit ein paar Dialogen zum Neuanlegen von Kunden.
- Dieselbe etwas modifizierte Maske gibt es zum ändern von Kunden.
- Und es gibt noch eine Kundenselektion

 

[KSG9|sebastian]

Eine sinnvolle Trennung in Projekte erleichtert das arbeiten. Es kann sinnvoll parallel gearbeitet werden, Weiterentwicklung ist einfacher zu machen, die Abhängigkeiten werden sinnvoll eingegrenzt u.s.w.

Wenn du unbedingt alles in ein Projekt verpacken willst kommt es stark auf die Menge an Klassen an.
Sofern die ganzen Funktionen nur aus sehr wenigen Klassen bestehen würde ich die Trennung zuerst
mit Sourcefoldern machen. Für jede Schicht einen Sourcefolder (src/gui, src/service, src/database oder so).

Für die GUI würde ich Controller, View und evtl. Modelpackages machen. Services würde ich höchstens trennen in
fachliche Services und Basisklassen (AbstractService in ein "core"-package, ServiceGetKunde in das "service"-Package).

Beim Datenbankpackage würde ich es ähnlich machen. core-Klassen in ein Package und z.B. DAOs (fals es welche gibt) in ein anderes Package.

Wenn das ganze größer wird kannst du entweder pro Fachlichkeit einen Sourcefolder machen, besser aber in mehrere Projekte aufteilen.
Wenn du das ganze natürlich mit Maven o.ä. machst bist du relativ festgenagelt auf die Struktur.

Dann würde ich oben genannte Struktur so umbrechen dass aus den Sourcefoldern Packages werden.

Gruß Sebastian

 

[eskimo328]

Problem bei vielen Projekten ist derzeit, dass wir mehrer Kunden haben. Unsere svn Branches sind nach Versionen aufgeteilt.
Wenn ich nun gerade mal nicht im TRUNK sondern in einem BRANCH eine Änderung mache, was oft vorkommt, dann muss ich per rechts-klick -> Team-> Switsch to another Branch jedes Projekt switchen. Hätte ich nur ein Projekt zum Switschen, wäre das effektiver.

 

[maki]

Branching ist wieder ein ganz anderes Problem
Hat etwas mit Configuration- und Changemanagement zu tun, Baselines, etc. pp.

 

[KSG9|sebastian]

Hihi, also willst du die Architektur der Anwendung so festlegen dass es aus SVN und deinen täglichen Arbeitsablauf passt?

Kleines Beispiel:

Ich arbeite täglich mit 4-5 verschiedenen Versionen unserer Software.
Wir betreuen im Team 26 Module (20-100 Klassen pro Modul). In jeder Softwareversion ist auch
eine andere Modulversion dabei. In jeder Version sind die Module teilweise sehr unterschiedlich was Funktionen angeht.

Um das ganze sinnvoll hinzubekommen gibt es z.B. Workspaces! Pro Version ein Workspace funktioniert zum Beispiel gut.
Dann hast du für jeden Kunden einen Workspace, was zum arbeiten eh Sinn macht.
Und wie machst du bitte eine Änderung wenn du nur ein einziges Projekt auf einen Branch switchst? Habt ihr nur ein Projekt oder wie?
Falls nicht geht's doch sowieso nicht, da ein Projekt in Version A sicher nicht zu den restlichen Projekten mit Version B passt.

Und ich glaube du solltest die Architektur der Anwendung nicht von irgendwelchen Faktoren wie z.B. Configmgmt. abhängig machen.
Die Architektur muss sauber sein, welcher auch immer du folgen magst. Da gibts kein Schwarz oder Weiß. Die Architektur muss zum Produkt passen und sauber, wartbar (etc. pp) sein.

Wie du diese Anwendung dann entwicklest, betreust, versionierst u.s.w. ist ein ganz anderes Problem.

 

[eskimo328]

Ich bin für ein projekt zuständig (die java-swing anwendung um die es hier geht). Etwa 10 Kunden haben diese Anwendung im Einsatz. Es handelt sich im übrigen um eine mobile Auftragserfassung.

Wir haben dafür ein svn-repository das aufgeteilt ist in TRUNK und BRANCHES.
In meinem Eclipse habe ich unter anderem zwei Working Sets namens "Anwendung TRUNK" und "Anwendung BRANCH". Die Anwendung hat als Beispiel die Versionsnummer 1.0.1. Nun gibt es im Repository unter BRANCHES ein Ordner "1.0".

Wenn ich nun Für Kunde A ein Bug beheben muss, dann weiß ich z.B. das bei Kunde A die Version 1.0.1 im Einsatz ist. Also öffne ich die Java Projekte unter dem Working Set "Anwendung BRANCH" und switch die zugehörigen Java Projekt auf den entsprechenden Branch. Wenn ich fertig mit der Änderung bin, wird alles commited und in den TRUNK gemerged.

Ähnlich funktioniert dass mit unserem Webshop. Für den ich jedoch nur selten Entwicklungen machen, dafür ist jemand anders zuständig. Jedoch verfahren wir damit genauso. Es gibt ein Workspace etc. ...

 

[KSG9|sebastian]

Jo, aber dann ist das Problem ja hausgemacht.

Wieso dieselben Projekte in verschiedenen Versionen im gleichen Workspace?

Jedesmal einen switch zu machen -> da würd ich verrückt werden. Zumal ein SVN-Switch ja auch nicht gerade das schnellste ist.

 

[eskimo328]

Derzeit besteht unsere Swing Anwendung aus 6 Java-Projekten. Mit Projekt meine ich "Eclipse->File->New->Java Project". Die einzelnen Java Projekte lauten sind u.a.
"INIT" (grundlegendes zeug, z.B. eine Klasse Version.java enthält die Versionsnummer),
"SOURCE" (eigentliche anwendung inkl. gui, business logic, sql etc. Main-Methode)
"AIA" (Schnittstelle zum ERP-System)
"LIBS" (Librarys wie derby.jar ...)

Jedes Projekt bildet eine Jar. Diese Projekte sind nun unter TRUNK eingecheckt bzw. in einem Working Set namens TRUNK ausgecheckt. Demnächst bekommt der Kunde z.B. ein größeres Update. Dann wird der TRUNK ausgeliefert. Natürlich getestet und so. Danach wird davon ein BRANCH mit der neuen Version erstellt. (Die Versionsnummer wird hochgezählt.)

Danach werden z.b. neue entwicklungen im TRUNK gemacht und eingecheckt etc.
Wenn ich nun bei dem Kunden der das Update bekommen hat, ein Bug beheben muss, werden alle 6 Projekte auf diesen BRANCH geswitcht, die Änderung gemacht und wieder eingecheckt und danch in den TRUNK gemerget.

Ist das verständlich so?
In der Vergangenheit wurde das ebenso gemacht. Zudem ist der Code nicht wirklich sauber getrennt, erweiterbar, etc. Deswegen möchte ich ja endlich mal eine saubere Struktur festlegen, an die man sich zu halten hat etc.

 

[Janus]

Ich hab für jeden branch einen eigenen Workspace (sind normalerweise immer so um 5-6). Würd bekloppt werden, wenn ich jedesmal mittels SVN switchen müsste.

 

[eskimo328]

vielleicht ist es ja auch sinnvoller, wenn wir für jeden Kunde ein Branch erstellen und nicht für Versionen?!
Aber zurück zum eigentlichen Thema. Nach dem Vorschlag von KSG9|sebastian würde die Struktur dann folgendermaßen aussehen (jetzt mal egal ob in einem Projekt, src-folder oder mehreren projekten verteilt)?

+ gui
   + model
       - kunden
       + statistik   
           - statistik 1
           - statistik 2
   + view
       - kunden
       + statistik   
           - statistik 1
           - statistik 2
   + controller
       - kunden
       + statistik   
           - statistik 1
           - statistik 2

+ service
   - core
   + service
       - kunden
       + statistik   
           - statistik 1
           - statistik 2

+ db
   - core
   + dao
       - kunden
       + statistik   
           - statistik 1
           - statistik 2

 

[maki]

vielleicht ist es ja auch sinnvoller, wenn wir für jeden Kunde ein Branch erstellen und nicht für Versionen?!

Warum sich nicht gleich in Software CM einlesen, Literatur gibt es genug, dann versteht man auch vielleciht was mit Baselining gemeint ist und warum das alles so komplex ist, inkl. Vor- und Nachteile, aber sowas aus einem Forum "lernen".. naja, dann bitte nicht beschweren.

 

[eskimo328]

Werde mir wohl mal "Moderne Software-Architektur" durchlesen.

Vielleicht können mal ein paar sagen, wie Sie ihre Projekte aufgebaut haben.

 

[eskimo328]

Habt ihr mir Empfehlungen zu guter SoftwareCM Literatur?

 

[TheDarkRose]

Werde mir wohl mal "Moderne Software-Architektur" durchlesen.

Vielleicht können mal ein paar sagen, wie Sie ihre Projekte aufgebaut haben.

Hab ich mir auch zugelegt, liest sich ganz gut.