[GWT + RPC + App engine] Grundaufbau eines Projektes

[lordcarlos]

Hallo liebe javagemeinde.

Ich mache gerade mein erstes eigenes Projekt mit GWT and App Engine.
Wo sollen die datenmodel klassen am besten hin? Client, shared oder Server side?

Ich will ein einfaches Auktionshaus schreiben welches man im nachhinein moeglich leicht einer bestimmten Situation anpassen kann. ein paar beispiel klassen:
[java=12]@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class UserProfile implements IsSerializable {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
@Extension(vendorName="datanucleus", key="gae.encoded-pk", value="true")
private String id;
@Persistent
private String firstName;
@Persistent
private String lastName;
//Und noch mehr einfache typen
//getter setter etc.
}
[/code]
oder auch
[java=13]@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Auction implements IsSerializable {

@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
@Persistent
private String titel;
//snip
@Persistent
private AuctionStatus auctionStatus;
@Persistent
private Contract contract;
@Persistent
private Bid bestBid;
@Persistent
private UserProfile owner;
//getters setters etc.
}[/code]

Momentarn ist das so das diese datanmodel klassen im client teil liegen wo auch ein $klassenname Service.java liegt was so aussieht:
[java=11]@RemoteServiceRelativePath("auction")
public interface AuctionService extends RemoteService {
public void addAuction(String title, Date endDateAndTime,
Date startDateAndTime, UserProfile owner, Contract contract);

public void removeAuction(long id);
public Auction[] getAllAuctions();
public Auction getAuctionById(long id);
}[/code]
Dazu erstellt mit eclipse auch noch eine passende $fooServiceAsync klasse.
Im server teil habe ich dann eine $fooServiceImpl.java die, die objecte in eine datanbank (app engine) speichert.
Das funktioniert alles wunderbar.

Doch habe ich wohl nicht weit genug gedacht, denn die berechnungen (z.B. Gebot A ist hoeher als B) sollte ja sicherheitshalber auf der server seite sein. Deswegen werde ich wohl da die datamodel klassen brauchen.

Sollte meine $fooService.java klassen so sein das sie nur einfache typen uebertragen und nicht die objecte? getAuctionTitle, get auctionstartDateTime .. etc. waeren viele getters und setter, dazu muesste ich die auf der clientseite wieder zusammen frikkeln. Hoert sich umstanendlich an.

Ein paar Tips und Tricks wie ich so ein Projekt aufbaue waeren hilfreich. Es muss nicht vorgekaut sein, aber mir den Weg zeigen.

Danke fuer die Aufmerksamkeit.
lord carlos

 

[lordcarlos]

*push*
Ich versuch es erstmal indem ich die daten object klassen (nennt man die ueberhaupt so?) in shared rein packe.
Wenn jemand dazu oder generell Tipps hat, immer her damit.

 

[darekkay]

Ich kann mal kurz einen möglichen Ansatz beschreiben:

1. Client: hier kommen ausschließlich Sachen drauf, die auf dem Client angezeigt werden müssen
2. Server: hier befinden sich alle größeren Berechnungen oder Datenbankoperationen; Speichern und Laden der Daten.
3. Shared: alles, was sowohl der Client als auch der Server braucht

Da du die Objekte (z.B. Userprofile) sowohl auf dem Server als auch Client benötigst, gehören diese in das Shared-Package (nicht vergessen, diese Klassen Serializable zu machen).

Speziell für dein Beispiel:
- ich glaube nicht, dass der Vergleich, welches Gebot höher liegt, auf dem Server geschehen sollte. Die Berechnung ist so einfach, dass das Schicken und Zurückgeben lassen mehr kosten würde
- du musst dir Gedanken machen, wie du deine Daten verwalten möchtest. Mit Hibernate kannst du bsp. direkt Objekte in einer SQL-Datenbank abspeichern - dafür muss man sich aber erstmal einarbeiten. Unabhängig von der Art geschieht die Umwandlung auf dem Server. Im Prinzip sieht das so aus: Du möchtest eine Auktion mit einer bestimmten ID haben. Rufst damit die asynchrone Service-Methode getAuctionById(String) auf. Der Server bekommt die Anfrage, erstellt ein "Auction" Objekt und füllt es mit den Daten (hier würde eben die Art der Speicherung eine Rolle spielen). Die aufrufende Methode bekommt dieses Objekt dann als "result" zurück, und du könntest es beispielsweise in deiner View anzeigen lassen. Die andere Richtung sieht genauso aus: möchtest du ein Profil abspeichern, sendest du dein (ggf. verändertes) Objekt zum Server, und dieser kümmert sich um das Speichern der Daten.

 

[lordcarlos]

Danke darekkay
Ich habe die Daten klassen jetzt in shared, scheint ganz gut zu funktionieren.

Der Vergleich, welches Gebot höher liegt, werde ich wohl auf beiden seiten machen. Client um unoetigen datenverkehr zu vermeiden, und server um sicherzustellen das der client nicht manipuliert wurde (oder netzwerk fehler, lag, was auch immer)

 

[JohannisderKaeufer]

So wie ich GWT verstanden habe kommt in shared, das rein, was auf Client und auf Serverseite gebraucht wird.

Prinzipiell würde ich die Datenklassen auch in shared verstauen, wenn es schnell gehen soll. Das kann aber einen Nachteil haben, wenn du beispielsweise in einem UserProfile auch z.B. ein Passwort/PasswortHash oder eine Email-Adresse, die nicht öffentlich sichtbar sein soll untergebracht hast.

Wenn du dann einem Nutzer ein fremdes UserProfile anzeigst, bei dem diese Felder ausgeblendet sind, übermittelst du in deinem Objekt diese Felder dennoch.

Daher würde ich imho, die Datenklassen auf dem Server belassen und in shared, "value Object"e unterbringen, die lediglich Inhalt transportieren.

Für ein ähnliches, wenn nicht gleiches Problem das man bei J2EE antreffen kann, gibt es das Transfer Object Pattern. Dies würde ich mir an dieser Stelle etwas genauer ansehen um die Problematik genau zu verstehen.

Core J2EE Patterns - Transfer Object