Swing + EJB

[OlliL]

Hallo,

ich möchte gerne Die Business-Logik inkl. DB-Zugriff aus meiner Swing Applikation in EJBs auslagern und auf diese dann mittels Remoting von JBoss zugreifen.

Nun stellt sich mir gerade die Frage, wie man das vom Konzept her entwickeln sollte. Entwickle ich "ein Projekt" in Eclipse wo ich einerseits meine Beans entwickle und andererseits meine Swing-Komponenten oder mache ich daraus zwei Projekte in Eclipse? Ich hab mal letzteres probiert... es geht zwar, aber man hat ja wahnsinnige Code-Redundanz, da sowohl das Interface der EJB Komponente sowie das Businessmodell (z.B. "Kunde") in beiden Projekten vorhalten werden müssen....

Für mich spricht also aktuell alles dafür, das in einem einzigen Projekt in Eclipse zu entwickeln.

Aber - ich habe mal in das deployte JAR geschaut was dem JBoss hingeworfen wird - dort sind (logischerweise) auch alle meine Swing-Client-Objekte enthalten. Was kann ich dagegen unternehmen? Im Grunde müssen auf den JBoss nicht die Client-Objekte, und in den Client müssen nicht die Beans....

Wie stellt man es am sinnvollsten an? Zwei Projekte in Eclipse oder eins? Wie bekomme ich eine Trennschärfe der generierten Strukturen für "Client" und "Server"?

 

[Landei]

Du kannst sogar drei Projekte machen, nämlich zusätzlich ein Projekt mit gemeinsam genutzen Interfaces und Business-Logik (aber möglichst ohne Hinweise auf Spring oder EJB), was die erwähnte Redundanz reduzieren würde. Das bindest du in den beiden anderen Projekten als jar ein, voilà...

Du kannst natürlich auch dem BBoM-Pattern folgen...

 

[mvitz]

Gegebenfalls sogar drei Projekte:
Projekt 1) Enthält alle Dinge, die du auf Server und Client benötigst.
Projekt 2) Enthält Dinge, die nur auf dem Server benötigt werden und hat eine Abhängigkeit zu Projekt 1
Projekt 3) Enthält Dinge, die nur auf dem Client benötigt werden und hat eine Abhängigkeit zu Projekt 1

 

[OlliL]

Ah OK - also eins mit den Beans, eins mit dem Client uns eins wo sich quasi die Entitäten (Business-Objekte) wie "Kunde" "Auftrag" "Haus" "Auto" "weiss der Geier" und Interfaces befinden... feine Idee 🙂

 

[OlliL]

Ich habe noch ein "Problem" 😉

In meiner Swing Applikation habe ich sagen wir mal 8 Eingabefelder. Diese Felder werden bisher in der Swing Applikation durch Validatoren während der Eingabe und nochmal abschliessend durch den Controller vor der Erzeugung des Businessobjektes validiert.
Diese Validatoren sind eher einzelne Methodensammlungen (validateBirthday(String bDay)) als Objekte. Für jedes Businessobjekt (Customer) gibt es somit auch eine extra Methodensammlung (validateCustomer).

Nun möchte ich EJB einsetzen und dorthin Dinge auslagern/bündeln. Mir widerstrebt es aber etwas aus den Eingaben in Swing das Customer Objekt in Swing zu formen und dem EJB zur Anlage in der DB direkt zu übergeben. Ich fände es besser wenn der EJB eine Validierung der übergebenen Daten vornehmen würde bevor er mit dem Customer Objekt hantiert. Überhaupt fände ich die Validierung in EJB besser aufgehoben da man sie dann für andere GUIs (z.B. Web-GUI) wiederverwenden könnte und sie dort nicht erneut implementieren müsste.

Somit habe ich mir überlegt eine Art Transfer-Objekt zu machen welches nur einfache Datentypen (String, Boolean) enthällt welches sich so z.B. auch in Swing abbilden lassen. Dann fülle ich in meinem Swing-Controller dieses Transfer-Objekt welches dann das eigentliche Business-Objekt "Customer" auf dem Application-Server formt. Validierungen finden dann in diesem Transfer-Objekt statt und führen im Fehlerfall zu einer Exception. Die Validierungsfunktionen des Transfer-Objektes werden in den Setter-Methoden des Transfer-Objektes aufgerufen, aber sind auch public, so das man sie auch bereits in der GUI verwenden kann.

Da stellt sich dann natürlich wieder die Frage, wie sinnvoll es ist während der Eingabe bereits "fachliche" Validierungen mittels EJB vorzunehmen, da das ja auch zu einer gewissen Latenz führt und die Eingabe durch den Anwender als "zäh" gestalten kann. Macht es da Sinn eine zweischichtige Validierung vorzunehmen? also neben den "Transferobjekten" welche im EJB liegen und alle Validierungen vornehmen solche Basis-Validierungen wie "Pflichtfeld", "lässt sich der String in eine Zahl konvertieren?" in dem Client "nochmal" zu programmieren?

Client:
- Dateneingabe
- Basisvalidierung der Daten während Eingabe (Format, Not Null)
- Ablage der Daten in einem Model der View
- Erzeugung der Transferobjekte beim "Speichern" via EJB (ein Überführen des Swing-Models in das Transfermodel)

Server (EJB):
- Detailvalidierung beim erzeugen der Transferobjekte Rückmeldung via Exceptions
- Erzeugen der Businessobjekte
- lesen/schreiben der Businessobjekte via Hibernate von/nach MySQL

Solch ein Transferobjekt würde dann so aussehen:

public class CustomerTO {
	private Customer customer;
	
	public CustomerTO() {
		customer = new Customer();
	}
	
	
	public void setCustomerID(String cID) {
		validateCustomerID(cID);
		customer.setCustomerID(Integer.parseInt(cID));
	}
	
	public void validateCustomerID(String cID) {
		// hier die Validierung
	}
	
	// weitere Getter + Setter + Validierer
	
	public void addCustomer() {
		// übergabe des internen Customer-Objektes an Hibernate "INSERT"
	}
	
	public void updCustomer() {
		// übergabe des internen Customer-Objektes an Hibernate "UPDATE"
	}

}

Das Business-Objekt:

public class Customer {
	private int customerID;
	
	public void setCustomerID(int cID) {
		customerID = cID;
	}

	// weitere Getter + Setter 
}

Was haltet Ihr von dem Ansatz bzw. wie würdet Ihr das designen?