fth Geschrieben 3. Februar 2009 Geschrieben 3. Februar 2009 Hallo, mein erster Beitrag, gleich mit einer Frage. Ich möchte einen Web Service schreiben, der zum Einen CRUD-Funktionen auf relevanten Daten unserer Datenbank realisiert und zum anderen bestimmte Operationen der Logik erfüllt. Wie dem auch sei... Ich möchte wissen, ob man bei der Parameterübergabe eher Komplex-Objekte verlangt oder besser die einzelnen Komponenten des Komplex-Objekts. Sprich: Person besteht aus id, name, vorname, personalnr. Ist es besser für eine Schnittstelle: public String createPerson(Person person); oder public String createPerson(long id, String name, String vorname, String personalNr); zu definieren? Gibts da Meinungen? Fred Zitieren
Schiller256 Geschrieben 3. Februar 2009 Geschrieben 3. Februar 2009 Ich finde den Weg mit den komplexen Objekten besser denn wenn du zu einer Person noch ein zusätzliches Attribut erfassen willst dann passt du die Klasse Person an die Schnittstelle selbst bleibt davon unberührt. Viele Parameter in einer Methode sind auch recht schnell unübersichtlich. Denn welche Parameter sind denn optional und welche nicht? Zitieren
fth Geschrieben 3. Februar 2009 Autor Geschrieben 3. Februar 2009 (bearbeitet) Wobei eine Anpassung der Komplexklasse ja auch wieder eine Änderung bei dem Client, der die Schnittstelle des Web Service importiert hervorruft. Aber klar, so ändert sich die eigentliche Schnittstellenbeschreibung nicht. Stimmt. 1. Der Hintergedanke war eigentlich der, was der Implementierer des Clients machen müsste. Er muss ja dann auch Komplexobjekte vom Typ (hier Person) erzeugen und verwenden. Das ist mit Axis2 recht simpel und funktioniert ganz gut, indem man einfach die importierten Stubs anwendet. Aber klappt das auch so einfach bei anderen Implementierungen für andere Progsprachen? gSOAP++, Java WS und was es noch so gibt, etwa in der .NET Welt. Das durchschaue ich jetzt nicht so sehr, denn ich bin frisch in der WS-Welt und im Moment ein bisschen Java (Axis2) zentriert. 2. Ich fühle mich auch etwas unwohl dabei, CRUD-Funktionen mit einem WS zu implementieren. Ich habe so etwas noch nicht gesehen bisher in Beispielen. Eigentlich werden ja WS immer für holeMirMalDieUndDieInformationen(ParamTyp param) Funktionen geschrieben- also Dienste, die die Logik schön kapseln. Aber eine andere Lösung sehe ich nicht. 3. Die ID's und equals. Wenn ich eine id als Parameter verlange (im Komplexobjekt oder auch als Parameter in der Schnittstelle), dann zwinge ich den Anwender ja dazu eine ID zu erzeugen und die IDs bei sich zu führen. Ich würde diese ID wohl als Primärschlüssel anwenden in der Datenbank. Dann kann darüber gesucht werden. Oder wie sollte readPerson() aussehen? public Person readPerson(long id); public String[] readPerson(String personalID); Es muss doch einen common sense bei diesen Fragen geben, damit man nicht später über Fragen stolpert, die man jetzt durch etwas mehr Denken/Forschen beseitigen kann. Bearbeitet 3. Februar 2009 von fth Zitieren
Schiller256 Geschrieben 3. Februar 2009 Geschrieben 3. Februar 2009 Beim Design eines Webservices solltest du grundsätzlich erstmal Technologie- und Implementierungsneutral bleiben. Wie du dann aus deiner WSDL und XSD Dateien auf konkreten Code kommst ist erst zweite Schritt. Denn wie du schon richtig festgestellt hast gibt es hier für beide Seiten (Client und Server) bereits unterschiedlich gute Generatoren. Wieso nicht auch CRUD Funktionen über einen WS kapseln? Denn deine CRUD Funktionen kapselst du doch sicherlich auch in einem DAO. Die Webservice Schnittstelle ist eigentlich nur noch mal eine Schicht weiter oben. Im Webservice kannst du dann noch weitere Aufgaben durchführen bevor du die eigentliche Operation auf die Datenbank ausführst. Deinen 3. Punkt habe ich nicht so ganz verstanden. Die IDs müssen nicht im Client gespeichert werden. Wenn du die eindeutige ID nicht kennst dann holst du dir erstmal eine Liste mit möglichen IDs und lässt den Benutzer dann die richtige auswählen. Kann aber auch sein das ich die Frage nicht richtig Verstanden habe. Zitieren
fth Geschrieben 4. Februar 2009 Autor Geschrieben 4. Februar 2009 Deinen 3. Punkt habe ich nicht so ganz verstanden. Die IDs müssen nicht im Client gespeichert werden. Wenn du die eindeutige ID nicht kennst dann holst du dir erstmal eine Liste mit möglichen IDs und lässt den Benutzer dann die richtige auswählen. Kann aber auch sein das ich die Frage nicht richtig Verstanden habe Moin. Was ich meine hängt auch mit dem 2. Punkt zusammen. Wenn ich CRUD bereitstellen will auf den einzelnen Datenobjekten (sprich: Datenbanktabellen), dann muss ich dem Anwender eine Möglichkeit geben, ein bestimmtes Auswählen zu können. Stichwort: Vergleichsmerkmal. Beim Objekt vom Typ Person wäre das also entweder: public Person getPerson(long id) { return Container.getPersonById(id); } oder public Person getPerson(String personalId) { return Container.getPersonByPersonalId(personalId); } oder public Person getPerson(String name, String vorname, String personalId) { return Container.getPerson(new Person(name, vorname, personalId)); } wobei public class Container { public Person getPerson(Person p) { for (Person item : personList) { if (item.equals(p)) return item; } return null; } } } D.h. in Container wird equals benutzt. Mit equals definiere ich wann ein Objekt vom Typ Person gleich ist. Dabei habe ich aber eine Alt-Datenbank, auf die ich aufsetzen muss. Also, ich beschreib mal kurz die Systemumgebung: Wir haben zwei Systeme LS (lokales System) und FS (fremdes System). Es gibt jeweils zwei Datenbanken mit unterschiedlicher Logik in LS und FS. Am LS wollen wir die Möglichkeit schaffen, dass das FS über eine Art 3. Logik (das stellt eben die Web Service Schnittstelle dar) mit unserem System Daten austauschen kann. Dabei gibt es Gemeinsamkeiten und Unterschiede. Beispiel: Im FS werden Daten gehalten, die Beschreiben, dass eine PRIVATPERSON in einem SUPERMARKT OBST kauft. Im LS wird beschrieben, dass eine HÄNDLER in einem ELEKTROGESCHÄFT ELEKTROGERÄTE kauft. (Ich lasse jetzt mal Spezialisierungen weg, dass der Händler Rabatt bekommt, oder so was). Also schaffen wir eine Schnittstelle, die von der Logik her beschreibt, dass eine PERSON an einem ORT ETWAS kauft. Einfach Abstraktion... Eigentlich gibts da erstmal ein Abbildungsproblem zwischen diesen 3 Logiken, das zu klären ist. Zurück zur Ausgangsfrage: Wenn ich jetzt in diese Schnittstellenlogik die spezifischen Primärschlüssel (id) als Vergleichsmerkmal einbringe, dann erscheint mir das zu genau. Du würdest so etwas als WS-Operation vorschlagen wollen: public long[] getPersonIds(); Um alle id's der PERSON zurückzubekommen? Irgendwie gefällt mir das nicht so richtig. Ach ich weiß nicht. Muss nochmal drüber nachdenken... Fred Zitieren
Schiller256 Geschrieben 4. Februar 2009 Geschrieben 4. Februar 2009 Ich verstehe dein Problem gerade überhaupt nicht. Wenn du deine Person kennst also den Primärschlüssel dann kannst du doch darüber auf die Datenbank zugreifen. Dass du den Primärschlüssel kennst bedeutet doch nicht automatisch das er auch im Client gespeichert werden muss. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.