Laden...

Webservice richtig designen: echte Objekte verwenden oder Key-Value-Pairs

Erstellt von madjoe vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.637 Views
M
madjoe Themenstarter:in
90 Beiträge seit 2009
vor 13 Jahren
Webservice richtig designen: echte Objekte verwenden oder Key-Value-Pairs

Hallo,

ich versuche gerade eine kleine Datenbankanwendung strikt nach SOA Maßstäben zu programmieren (auch wenn im Moment alles in einem Projekt bleibt, aber der Übung dieses Konzepts willen).

Jetzt steh ich nur leider etwas an, wie man am besten die Schnittstelle gestalten sollten. Einerseits wird ja gesagt, dass die Methoden atomar sein sollen, weil man ja praktisch keine wirklichen Transaktionen abdecken kann, andererseits soll ja eine möglichst gute Wiederverwendbarkeit bestehen. Im Internet findet man zwar viel allgemeines trendige Zeug zu dem Thema allá "Projektmanagement-BlaBla", aber wirklich vernünftige Beispiele hab ich bisher kaum gesehen, die über ein

String echo(String s)

hinausgehen.

Mein konkretes Problem:

Ich habe nun zwei Domain-Objekte Customer und Address; ein Kunde soll mehrere Adressen besitzen können. Bearbeitet werden soll das ganze aus Benutzersicht dann natürlich durch ein Formular, wo man dann nur einmal am Schluss speichert.

Wie würdet ihr das jetzt gestalten? Ich hätte ja gesagt, dass man sich ein entsprechendes Objekt zusammenbauen müsste, dass diese ganze Daten beinhaltet und serialisierbar ist. Aber dann ist die Methode wieder praktisch nur für diesen Use-Case brauchbar.

Desweiteren stellt sich auch noch die Frage: ist es schlau alles als Objekt zu handhaben, oder macht es hier mehr Sinn mit Name/Value Paaren zu arbeiten, damit man flexibler ist (also DataSet, ist dann halt .NET spezifisch ...) ?

Wäre echt dankbar für ein paar wegweisende Tipps!

MfG
Joe

2.298 Beiträge seit 2010
vor 13 Jahren

Eine Anwendung sollte Grundsätzlich zwar flexibel sein, aber nicht zu flexibel.

Wenn wir von einem reinen .NET Webservice reden, brauchst du auch nichts als serialisierbar kennzeichnen. 😃

Der Ansatz mit dem Objekt ist schon richtig. - Für einen Kunden würd ich das so sehen, dass er seine allgemeinen Properties hat und zusätzlich eine Liste der Adressen.

Das kannst du ja letztendlich so auch an den Webservice übergeben, bzw. von ihm abrufen.

Die Sache mit den Key-Value Paaren, da bin ich mir unsicher. - Wenn es sich anbietet ok, aber im konkreten Fall für mich eher weniger.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

M
madjoe Themenstarter:in
90 Beiträge seit 2009
vor 13 Jahren

Danke für die bisherige Antwort.
Um meine Gedankengänge noch etwas zu konkretisieren:

Ich möchte in etwa folgendes machen:

interface CustomerService {
     
    Customer getCustomerByID(int id);
    void save(Customer customerData);
    Customer.....Somewhat[] findCustomers(Filter filter);

}

Die Frage ist für mich jetzt: ich möchte einmal praktisch einen Kunden mit all seinen Attributen plus Adressen, also sowas wie eine Sicht, die sich zum Bearbeiten in einem großen Formular anbietet. Andererseits möchte ich für eine Suchfunktion zwar eventuell Adressen miteinbeziehen (z.B. PLZ), diese Daten aber nicht unbedingt als Ergebnis zurückgeben, sondern nur die wesentlichen Attribute (z.B. Name). Einmal aber vielleicht die Kombination aus Hauptattributen und einer Hauptadresse.

Ist es hier nun gänge Praxis sich für alle Basis-Daten Trägerobjekte anzulegen (also CustomerData, AddressData, etc.) und diese dann mit speziellen Result-Objekten zu verknüpfen, z.B:



class CustomerAddressResult {
    CustomerData customerData;
    Address[] addresses;
    ....
}

....
CustomerAddressResult getFullCustomerById(int id);

... oder liege ich da auf dem Holzweg?

Dieses Thema bereitet mir anscheinend deswegen ein paar Schwierigkeiten, weil ich wie die meisten Naturwissenschaftler unnötigen Schreibaufwand vermeiden möchte. Aber ich muss mir solche Dinge auch nicht unbedingt teuer durch massenhaft generierten Code erkaufen.

MfG
Joe

S
8.746 Beiträge seit 2005
vor 13 Jahren

Schreibaufwand sollte kein Kriterium sein. Du solltest allerdings beachten, dass Webservices oftmals über langsame Netze (Internet) abgewickelt werden. Man sollte also die Granularität der Abfragen auch unter dem Gesichtspunkt der Datenmenge und damit der Geschwindigkeit betrachten.

M
madjoe Themenstarter:in
90 Beiträge seit 2009
vor 13 Jahren

Schreibaufwand sollte kein Kriterium sein.

Wenn ich da so an wirtschaftliche Forderungen denken, würde ich schon sagen, dass das ein Kriterium sein könnte 😃

Du solltest allerdings beachten, dass Webservices oftmals über langsame Netze (Internet) abgewickelt werden. Man sollte also die Granularität der Abfragen auch unter dem Gesichtspunkt der Datenmenge und damit der Geschwindigkeit betrachten.

Ja, genau deswegen waren auch die Key/Value Pairs in meinen Denkprozess inkludiert. Das der Client nur die Felder als Parameter angibt, die er auch momentan zur Präsentation haben möchte. Allerdings glaub ich, dass man sowieso gegen die obere Schranke programmieren sollte.

Ich denke ich werde das jetzt durch eine Kopie des Domain-Models lösen, welches allerdings je nach Anwendungsfall verknüpfte Elemente anbietet oder einfach NULL lässt, ergänzt durch ein paar speziellere DTO (vgl. Views in Datenbanken) und abgerundet durch Response-Objekte wie Result, UniqueResult, PagedResult, etc.

M
madjoe Themenstarter:in
90 Beiträge seit 2009
vor 13 Jahren

hallo,

vorweg: bevor ich das forum zumülle, hab ich mir gedacht ich setze diesen thread fort, auch wenn er schon älter als 2 monate ist, aber das thema beschäftigt sich allerdings noch damit.

konkret geht es mir um das einholen der meinung folgenden sachverhalts:

ich habe ein transferobjekt das folgendermaßen aussieht:


class CustomerData
{
    private string lastName;
    private string firstName;
    private string eMail;

    // und noch viele weitere attribute ...
}

jetzt komm ich drauf, dass eine weitere anwendergruppe zwar auch benutzer abfragen soll, allerdings die email-adresse z.B. nicht freigegeben werden soll.

exkurs:
bezüglich verteilter anwendungen ist das internet nicht gerade großzügig wenn es um vernünftigen informationen á best practice geht - und ich hab bestimmt schon stunden danach gesucht...

jedenfalls, was wäre hier die "richtige" lösung? was würdet ihr empfehlen?

  1. eine neue transfer-klasse anlegen? ... hat dann aber auch zur konsequenz, dass ich routinen auf der client-seite nicht wiederverwenden kann, da der typ nicht kompatibel ist. ich würde allerdings auch gerne validierungs-informationen einbaun, die kann ich dann auf client und server -seite nutzen.
  2. die nicht benötigten attribute null setzen? ... wäre zumindest in die lese-richtung eine einfache lösung, fragt sich nur, wie dass dann in die schreib-richtung gelöst werden soll - gerade in kombination mit validierung.

... naja und wenn dann vielleicht noch eine ganze reihe an attribute dazukommen, die ohnehin nur ein administrator zu sehen hat - vl. wäre es dann sinnvoller eine ableitung zu machen auf z.B. AdminCustomerData (oder AdminUserData, je nachdem mit was wir es dann überhaupt zu tun haben).

wäre dankebar für denkanstöße, bzw. vielleicht auch sinnvollen internet-resourcen oder buchtipps zu dem thema. wobei ich mir ungern in diesem fall ein buch antun möchte, da ich mich damit jetzt ohnehin nur am rande beschäftige ...

mfg
joe

2.298 Beiträge seit 2010
vor 13 Jahren

edit
Erstelle mehrere Views, je nach Nutzergruppe zeigst du eben die entsprechende View an.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

M
madjoe Themenstarter:in
90 Beiträge seit 2009
vor 13 Jahren

Erstelle mehrere Views, je nach Nutzergruppe zeigst du eben die entsprechende View an.

hmm, nun mir geht es hier schon um das design einer allgemeinen objekt-orientierten api; also um etwas was ich auch per gewöhnlichem remoting verwenden kann, oder eventuell (vorallem in der testphase) auch gänzlich lokal ...

ich sehe nicht, wie mir hier "views" weiterhelfen. worauf genau beziehst du dich in diesem fall, auf MVC "views"?

2.298 Beiträge seit 2010
vor 13 Jahren

Bei der Aussage hab ich mich soweit ersteinmal garnicht auf irgend ein Pattern bezogen.

Es erschien mir nur erstmal als das logischste. Mehrere UserControls, die je nach Benutzerberechtigungen geladen werden.

Da du aber noch weiter gehst, wäre das wohl auch nicht der Weg der Erleuchtung.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |