WCF Webservice oder Datenbank direkt abfragen

Hi!

Wir stehen bei unserem neuen Projekt vor der Frage, ob wir vom Client direkt auf den MS SQL-Server zugreifen sollen oder der Client, also die ViewModels, auf einen Webservice zugreift, der dann wiederum auf den SQL-Server zugreift.

Das Projekt ist eine typische LOB-Anwendung. Geschäftsprozesse abbilden, Daten zusammensuchen, anzeigen, seltener Daten nach Excel exportieren usw... Softwareseitig wird es natürlich so oder so 3 logische Schichten geben.

Unser Hauptaugenmerk geht dabei in Richtung Authentifizierungsmöglichkeit, die durch den Aufruf über den Webservice prima gegeben wäre. Das ist zwar vom Kunden keine Anforderung, ist bei dem Projekt unserer Meinung nach aber durchaus sinnvoll. Skalierung wird wohl kein Thema werden.

Gibt es dabei grobe Nachteile? Wie sieht es bei der Geschwindigkeit aus? Ich meine damit realistische Szenarien, einfach aus dem Alltag. Gibt es da große Einbußen oder ist es nur ein kleiner Aufpreis.

Ist der Aufpreis beim Aufruf vom Webservice eher jeder Aufruf ansich (Roundtrip) und wenn dieser einzelne dann eine große Datenmenge zurückgibt, ist es auch kein Unterschied oder kommt es auch tatsächlich auf die Datenmenge an?

Gibt es da sonst noch "nervige" Nachteile? Dass man bestimmte Sachen bei der Entwicklung beachten muss, die uns dann stark aufhalten?

Vielen Dank schon mal!

Grüße,
Daniel

Ne 3-Tier-Architektur, was DB->Service->Client ja darstellt, ist in meinen Augen definitiv die bessere Wahl.

Du kannst im Service problemlos ein Caching integrierten, was ansonsten bei den Clients untergebracht werden müsste. Authentifizierung und Rechte-Level ist ebenfalls einfacher per Service umsetzbar.
Die Performance des ganzen ist nicht pauschal zu beantworten; liegt jedoch im unterem Prozentbereich, sodass die Architektur-Vorteile deutlich überwiegen. Es kommt aber auch an, was und mit welchem Protokoll übertragen wird.

Clients lässt man heut zu Tage in neuen Projekten i.d.R. nicht mehr auf die Datenbank los; optimal ist, dass es den Client gar nicht interessiert, wo und wie die Daten gespeichert werden.
Ein weiterer Vorteil ist es, dass die DB problemlos angepasst werden kann und die Clients nicht. Die Änderung muss nur im Service stattfinden (hier bietet sich auch eine API-Versionierung des Services an (ist üblich)).

Letzten Endes: ich rate Dir zur Service-Variante.

Hallo Daniel_3_17,

um welche Anwendung gehts? WPF, Silverlight?
Bei Silverlight geht der direkte Zugriff auf die DB ohnehin nicht.

Der Weg über WebService (wenn möglich TCP-Binding) ist in der (Erst-) Entwicklung ein wenig aufwändiger als der direkte Zugriff über die DB, aber du hast dadurch mehrere Vorteile:*Die DB ist vom Client wegabstrahiert - kann somit leichter angepasst, getauscht etc. werden. *Der DB-Zugriff vom WebService aus läuft mit dem Dienst-Konto des WebService, das ist für die Rechte-Verwaltung in der DB wesentlich erleichternd. *In der DB brauchen nicht unbedingt die Rechte feingranular für die einzelnen Benutzer und Operationen vergeben werden. Mehr als der WebService dem Client anbietet kann in der DB einfach nicht gemacht werden. Der DB-Admin muss somit nur dem WebService vertrauen 😉 *Sollte es Änderungen in der DB-Zugriffslogik (z.B. andere Filterbedingungen) geben, so ist es einfacher den WebService zu aktualisieren, als alle Clients.

Es gibt aber auch Nachteile:*Debugging ist umständlicher *Exception-Handling aufwändiger um es richtig zu machen *CUD-Operationen sind aufwändiger zu implementieren, da der O/R-Mapper "auf der anderen Seite ist", d.h. es muss mit Attach, etc. gearbeitet werden. *Lazy-Loading ist nicht möglich.

Aber unterm Strich sehe ich - genauso wie Abt - die WebService-Variante vorteilhafter.

Tipp: für WCF darf der O/R-Mapper keine (dynamischen) Proxies generieren, weil diese nicht deserialisiert werden können (da der konkrete Typ dem Serializer nicht bekannt ist). Das kann bei den üblichen über eine Einstellung abgestellt werden.

Schau dir ggf. auch Microsoft Application Architecture Guide, 2nd Edition, Chapter 3: Architectural Patterns and Styles und Chapter 22: Designing Rich Client Applications an.

mfG Gü

Hi!

Vielen Dank für eure Anregungen. Es wird eine WPF-Anwendung, die nur im lokalen Netzwerk ausgeführt wird.

Ich werde heute ein Beispielprojekt machen um die von gfoidl angesprochenen Nachteile auskosten zu können. 😁

Grüße,
Daniel

Hi noch mal!

Komme ganz gut voran und soweit passt alles. Beim testen von geworfenen Exceptions aus dem Webservice bin ich aber darüber gestolpert, dass Visual Studio nicht wie gewohnt und bequem an genau der Stelle anhält an der die Ausnahme auftritt, sondern an der Stelle des Aufrufs vom Client. Das ist natürlich nicht sehr bequem. 😁

Per Breakpoint kann man schrittweise im Webservice debuggen, obwohl der Client gestartet wurde, aber wie bringe ich Visual Studio bei, dass es bei geworfenen Exceptions direkt im Code des Webservices anhält?

Danke! 🙂

Daniel

Hallo Daniel_3_17,

Im Menü -> Debug -> Exceptions (Ctrl + Alt + E) anhaken wie im Anhang.

Außerdem ist es vorteilhaft den WCF-Service als Fassade um die eigentlichen Service-Methoden zu gestalten, denn so können die eigentlichen Service-Methode separat (ohne WCF-Zeugs) getestet werden.

Falls du zu diesen "Dingen" noch fragen hast, erstell ein neues Thema ( [Hinweis] Wie poste ich richtig? Punkt 1.2).

mfG Gü

Hallo Daniel_3_17,

ganz vergessen, aber jetzt ist es mir wieder eingefallen: die ADO.net DataServices (auch als WCF DataServices) wären eine gute Alternative zum Service komplett selbst zu erstellen. Schau dir diese mal an, ob sie für dein Projekt taugen.

mfG Gü