Laden...

[WCF] Mehrere Services in einem Endpoint

Erstellt von rapisthesolution vor 9 Jahren Letzter Beitrag vor 9 Jahren 2.042 Views
R
rapisthesolution Themenstarter:in
36 Beiträge seit 2010
vor 9 Jahren
[WCF] Mehrere Services in einem Endpoint

Hallo,

ich habe einen Application Server, welcher meinen Clients per selbst geschriebener API Zugriff auf die Tabellen meiner Datenbank ermöglicht.

Hierbei kommt WCF und das Entity Framework zum Einsatz.
Ich bin momentan dabei meinen Code zu überarbeiten und etwas aufzuräumen.

Bislang sieht mein ServiceContract in etwa so aus...
D.h. ein Großteil der Logik liegt im Client - die Daten werden komplett zwischen Client und Server hin und her geschaufelt.


namespace ServiceInterface
{
    [ServiceBehavior]
    public class Service : IService
    {
        public byte[] GetTable1()
        {
            ...
        }

        public byte[] GetTable2()
        {
            ...
        }

        public bool SaveTable1(byte[] obj)
        {
            ...
        }

        public bool SaveTable2(byte[] obj)
        {
            ...
        }

        ...

    }
}

Mein neuer Ansatz soll die Logik komplett in den Server verlagern und die Datenmenge (im Hauptspeicher und auch der Traffic) soll mit Paging und ein paar anderen Mechanismen verringert werden.

Meine Idee war nun pro Tabelle einen ServiceContract zu definieren.
Über Sessions bleibt die jeweilige Instanz dann für die Dauer der Nutzung für den Client zugreifbar.


namespace ServiceInterface
{
    [ServiceBehaviorAttribute(InstanceContextMode=InstanceContextMode.PerSession)]
    public class Table1: ITable1
    {
        public byte[] Get()
        {
            ...
        }

        public bool Save(byte[] obj)
        {
            ...
        }

        ...

    }
}

Da in der Datenbank ca. 100 Tabellen liegen ist nun die Frage ob ich pro Service wirklich einen Endpoint erstellen muss oder ob es eine Möglichkeit gibt alle 100 Services in einem Endpoint zu bündeln.

Die nächste Frage ist natürlich ob mein Ansatz überhaupt Sinn macht oder es sinnvoller wäre einen allgemeinen Service für alle Tabellen zu definieren und einen entsprechenden Verteiler dahinter zu schalten. Wobei ich mir noch nicht sicher bin wie ich das bewerkstellige - generische Services sind ja leider nicht möglich.

Ich habe schon viel im Internet gelesen ohne eine wirkliche Antwort zu finden.
Vielleicht kann mir hier jemand auf die Sprünge helfen.

Vielen Dank im Voraus.

16.806 Beiträge seit 2008
vor 9 Jahren

Die Frage ist mit unter auch: wieso lieferst Du direkt volle Tabelle und keine spezifischen Objekte mit passenden Schnittstellen?
Das ist ja eigentlich nicht der Sinn von Services (jedenfalls im Kern).

Und nein. Ein Endpoint gehört fix einem Service.
Außer Du machst direkt in der Config bekannt, wer was handelt: Multiple Endpoints at a Single ListenUri

R
rapisthesolution Themenstarter:in
36 Beiträge seit 2010
vor 9 Jahren

Hallo Abt,

das ist in der Tat bislang so, wobei man die Tabelle natürlich entsprechend auf die Einträge filtern kann die man wirklich benötigt.

Das ist der Architektur der darunterliegenden Software geschuldet.

In der "neuen Version" würde ich aber nur jeweils einen Datensatz an den Client liefern. Vom Client aus gebe ich dann den Anstoß, wenn der nächste Datensatz benötigt wird.

Kriege ich ein Problem mit der Performance, wenn ich 100 Endpoints definiere?

Wenn ich den Weg über einen "Verteiler" gehe bliebe mir ja nur die Möglichkeit über Reflection eine generische Klasse/Methode aufzurufen.

211 Beiträge seit 2008
vor 9 Jahren

...
Das ist der Architektur der darunterliegenden Software geschuldet.
...

Warum dann auf etwas weiter aufbauen, das bereits nicht ganz optimal ist? Warum nicht das ganze wegkapseln damit man eine "sauberere" Architektur hat und auch den Konzepten hinter WCF (bzw. SOA) gerecht wird? Und warum "lieferst"du deine Entities als byte[]-Array aus? Dafür gibt es die Serialisierer in WCF, arbeite doch mit DTOs?

100 Endpunkte sind zwar möglich, aber spätestens der nächste Entwickler wird das selbe Problem haben wie du jetzt:
"Ich muss jetzt etwas machen was nicht im Sinne des Erfinders ist weil meine bestehende Architektur das verlangt..."

Überleg dir auch ob der Client auch wirklich 100 Tabellen einzeln haben möchte oder ob es nicht mehr einen "Context" gibt in dem er arbeitet? Ansonsten schau dir auch mal die WCF-Dataservices an?

Kontakt & Blog: www.giesswein-apps.at

R
rapisthesolution Themenstarter:in
36 Beiträge seit 2010
vor 9 Jahren

Ein byte[]-Array wird geliefert, da wir nicht mit dem Standard Serialisierer arbeiten, sondern mit protobuf. Wir arbeiten bereits mit POCOs.

Natürlich werden nicht 100 Tabellen auf einmal benötigt und müssen nicht immer gleichzeitig zugreifbar sein.

In jedem Teil der Software werden unterschiedliche Tabellen, mit unterschiedlichen Filtern benötigt.
Es ist unmöglich das zusammenzufassen. Aus diesem Grund ist ein (gefilterter) Einzelabruf der Tabellen notwendig.

Deshalb muss ich in meinem Service einen Einzelabruf der Tabellen möglich machen. Und das sind nun mal 100 Tabellen.

Wo ich wieder bei meiner eigentlichen Frage bin, wie das am performantesten zu bewerkstelligen ist.

Ob es Sinn macht 100 Endpoints zu definieren?
Ob ich einen einzelnen, universellen Service erstelle, welchem ich einen Parameter mitgebe und auf eine der 100 Tabellen verzweige?
Ob WCF überhaupt geeignet ist oder ein direkter Zugriff auf den SQL-Server mehr Sinn macht / performanter ist?

16.806 Beiträge seit 2008
vor 9 Jahren

Du fragst ob es sinn macht, 100 Endpoints zu definieren.
Wenn ich ehrlich bin macht Dein ganzes Vorhaben wenig sinn.

Aber Dir gehts doch gar nicht um denn Sinn, sondern um die Funktion.
Also macht halt.... 🤔

R
rapisthesolution Themenstarter:in
36 Beiträge seit 2010
vor 9 Jahren

Wieso schreibt man einen Beitrag in einem Forum?

Weil man selbst nicht weiter weiß und sich einen Tipp von jemandem erhofft, der mehr Erfahrung hat als man selbst.

Offenbar ist es aber unmöglich mir konstruktiv auf meine Fragen zu antworten.
Stattdessen wird man nur belächelt.

Und ich dachte immer es gibt keine dummen Fragen...

16.806 Beiträge seit 2008
vor 9 Jahren

Nein, aber Du trittst auf einer Stelle.
Es ist prinzipiell egal wo Du jetzt den "Murks" implementierst; die Basis "stimmt ja schon nicht" (bezogen auf den Grund-Sinn von Services).
Ich würde mir also über vieles Gedanken machen, aber nicht um so eine lapidare Angelegenheit, ob nun 100 Endpoints sinnvoll sind oder nicht.
Wenn der Rest Sinn machen würde, würde sich die Frage gar nicht stellen.

Manchmal muss man halt einfach mal was machen, statt rum zu drücken 😉
Ohne simples Ausprobieren wurde noch kein Erfinder geboren....

R
rapisthesolution Themenstarter:in
36 Beiträge seit 2010
vor 9 Jahren

Grundsätzlich bin ich ja offen für Neues - möglicherweise bin ich auch in meiner Denkweise zu festgefahren.

Wenn ich jetzt mal vom einfachsten Fall ausgehe:
ich möchte einen Datensatz über WCF aus der Datenbank auslesen.

Dann würde man doch eine Funktion im Service definieren, die da heißt "GetTable1ByID". Wenn ich nun mehrere Tabellen habe benötige ich die Funktion doch pro Tabelle oder nicht?

Also GetTable1ByID, GetTable2ByID, GetTable3ByID usw.

Oder liegt darin schon das Problem?
Ich kann es mir anders nicht wirklich vorstellen.

16.806 Beiträge seit 2008
vor 9 Jahren

Dir wurden doch jetzt ein paar Stichworte genannt.
Also ergreift die Eigeninitiative, die ein Entwickler haben sollte:
WCF - Get started
WCF Data Services 4.5
Pros and Cons of Data Transfer Objects (DTO)
WCF by Example - Response

R
rapisthesolution Themenstarter:in
36 Beiträge seit 2010
vor 9 Jahren

Naja, wenn ich mir das Beispiel ansehe komme ich wieder auf die gleiche Frage zurück, da dort ein eigener Service für die Tabelle Customer angelegt wird.
Die Beispiele kenne ich auch zu genüge.

WCF by Example - Chapter III - Response

Habe ich also mehrere Tabellen, brauche ich pro Tabelle einen Service.

Wo ich wieder bei meiner eigentlichen Frage wäre, ob ich wirklich 100 Services / Endpoints anlegen muss.

Da man mir darauf keine Antwort geben kann oder möchte kann das Thema denke ich geschlossen werden.

Vielen Dank trotzdem für die Mühe.

A
350 Beiträge seit 2010
vor 9 Jahren

Ich finde eure/deine Architektur Grundlegen falsch.
Man kann alle Daten Kapseln bzw die Zugriffe.

So haben wir zB nur einen Service der uns je nach übergebener Entität die Daten für eine gewisse Table zurückgibt

Und die Entität ist erstmal nur ein Interface , welches dann auf Serverseite dynamisch aufgelöst wird.

Noch eine Frage : Warum MÜSSEN unbedingt ALLE Tabellen übergeben werden ?

Bei einer Mehrschicht Architektur definierst du pro Schicht POCOs oder im DL halt DataEntitäten etc.
Du gibts in den WCF Services nur die Felder /Daten zurück die du wirklich brauchts und nicht stumpf alle.
Nach meinem Empfinden probierst du DatenEntitäten 1zu1 durch alle Schichten zu schleifen.

Überdenke doch bitte die Architektur, denn wenn du schon bis Serviceebene was neu machen kannst, kannst du sehr wohl die Architektur beeinflussen 😉

Grüße