REST-API im Vergleich zu direkten DB-Aufrufen in der Desktop-Anwendung

Ich plane derzeit eine Anwendung, die in einem Unternehmen verwendet wird. Es ist erforderlich, eine Desktop-Anwendung zu erstellen. Derzeit sind sie sich nicht sicher, ob die Anwendung in naher Zukunft auf Mobilgeräten oder im Browser verfügbar sein soll.

Ich habe zwei Möglichkeiten:

Greifen Sie direkt über die Desktop-Anwendung auf die Datenbank zu
Erstellen Sie eine REST-API und stellen Sie eine Verbindung dazu her

Kann ich eine REST-API verwenden, wenn die Anwendung nur eine Desktop-Anwendung im Unternehmen bleibt? Ich weiß, dass es möglich ist, aber ist es "der richtige" Weg? (Empfohlene Vorgehensweise)

Es gibt einige (mögliche) Vor- und Nachteile beim direkten Erstellen einer REST-API:

Nachteile:

Die Entwicklung dauert länger
Komplexer
Der Server erledigt mehr Arbeit
Sicherheitsprobleme
Langsamer? (Der Server und die Desktop-Anwendung befinden sich im selben Netzwerk.)

Vorteile:

Die Migration auf andere Plattformen ist einfacher
Die Geschäftslogik wird auch benötigt, wenn Sie die Datenbank direkt aufrufen. Die Entwicklung wird nicht mehr lange dauern
Gleiches gilt für die Komplexität
Sicherheit (wie von tkausl in den Kommentaren erwähnt)
Wartbarkeit (wie von WindRaven in den Kommentaren erwähnt)

— devz
quelle

Sie zählen wirklich Security issuesals Nachteil für die REST-API?

— Tkausl

Ich kann meine API beispielsweise mit OAuth2 und TLS schützen, dies führt jedoch zu mehr Arbeit. Ich weiß nicht, wie sicher ein direkter DB-Aufruf ist. ZB mit JPA. Deshalb habe ich ein Fragezeichen hinzugefügt, da ich mir nicht sicher bin.

— Devz

Nun, Sie können nicht weniger Sicherheit erhalten als ein direkter Datenbankaufruf, es sei denn, Sie geben root-login preis.

— Tkausl

Ein weiterer Vorteil: Eine Änderung der Geschäftslogik muss nur in der REST-API vorgenommen und auf dem Server bereitgestellt werden, nicht vorgenommen und dann jeder Client aktualisiert werden. (vorausgesetzt, die API-Schnittstelle ändert sich dadurch nicht)

— RubberChickenLeader

Läuft die Datenbank auf demselben Computer wie die Anwendung? Wenn nicht, würde ich nicht einmal über einen direkten Schreibzugriff auf die Datenbank nachdenken.

— CodesInChaos

Antworten:

Wenn es um große Anwendungen mit einer riesigen Datenbank geht, die Millionen von Datensätzen enthält, werden Sie schnell feststellen, dass eine einfache Auswahl, Aktualisierung, Einfügung und Löschung einfach nicht ausreicht.

Sie fangen also an, anders zu denken. Sie erstellen Prozeduren und Trigger, um kompliziertere Dinge direkt in der Datenbank zu erledigen, und das ist nicht sehr gut. Datenbanken bieten eine hervorragende Leistung bei der Ausführung von CRUD-Operationen. Lange Prozeduren? Nicht so viel.

Das Problem mit den Verfahren

Stellen Sie sich nun vor, Sie wechseln zu einer Datenbank, die das Konzept der Prozeduren nicht unterstützt. Was wirst du machen? Sie sind gezwungen, die Prozeduren stattdessen in Ihre Codebasis zu verschieben, wo Sie ziemlich sicher sein können, dass sie nach dem Programmieren in Java immer dort bleiben, unabhängig davon, für welches Datenbankmodul Sie sich entscheiden.

Ganz zu schweigen davon, dass Ihre Prozeduren normalerweise Teil Ihrer Geschäftslogik sind und es keine gute Idee ist, Ihre Geschäftslogik auf Ihre Codebasis und Datenbank zu verteilen.

Idealerweise sollten Sie immer einen Vermittler zwischen der Datenbank und dem Client haben, der seine eigenen Geschäftsregeln implementiert. Der direkte Zugriff auf die Datenbank ist keine gute Idee, da derjenige mit Zugriff direkten Zugriff auf die Tabellen hat und mit den vorhandenen Daten so ziemlich alles tun kann.

Nachteile

Die Entwicklung dauert länger: Natürlich erstellen Sie ein neues System, das zeitaufwändiger ist, als dem Client einfach eine Datenbankverbindungszeichenfolge zu geben und ihn die Abfragen schreiben zu lassen.
Komplexer: Komplexität eines Systems> Komplexität einer Datenbankabfrage.
Der Server erledigt mehr Arbeit: Nicht unbedingt. Mit gutem Design, Caching, ... können Sie die Last vom Datenbankserver auf den des Mediators verschieben.
Langsamer: In Bezug auf die Entwicklung? Ja. In Bezug auf die Geschwindigkeit beim Abrufen von Daten? Nein. Sie können Ihren Mediator mithilfe von Caches optimieren (z. B. - seit Januar 2016 beliebt - Redis, Elasticsearch) und tatsächlich Daten schneller liefern als eine einfache Datenbankabfrage.

Vorteile

Die Migration auf andere Plattformen ist einfacher: Migration auf eine neue Datenbank-Engine? Bestimmt. Den gesamten Mediator in eine neue Sprache migrieren? Nicht wirklich.
Die Geschäftslogik wird auch benötigt, wenn Sie die Datenbank direkt aufrufen. Die Entwicklung wird nicht mehr lange dauern: Wie bereits erläutert, ist das Verfahren problematisch.
Sicherheit: Mit der richtigen Autorisierung ist es definitiv viel sicherer, einen Mediator zu haben, als einem Benutzer direkten Zugriff auf die Datenbank zu gewähren, da Sie ihn auf die Endpunkte beschränken, auf denen nur die gewünschten Abfragen ausgeführt werden.
Wartbarkeit: Einer der besten Vorteile eines Mediators. Wenn es einen Fehler in einer API gibt, die Ihre Clients aufrufen, beheben Sie ihn, übertragen den Fix in Ihr VCS-Repository, erstellen Ihren Mediator aus der korrekten Version von VCS, die den Fix enthält, und alle Ihre Clients verwenden den Fix plötzlich, ohne dass sie dies benötigen Laden Sie ein Update herunter. Dies ist einfach unmöglich, wenn die Abfragen direkt in den Clientanwendungen gespeichert sind. In diesem Fall müssen Clients ihre Anwendung aktualisieren.

— Andy
quelle

Wie oft standen Sie vor der Herausforderung, zu einer Datenbank zu wechseln, die das Konzept der Verfahren nicht unterstützt, als Sie sie tatsächlich verwendeten?

— Harpun

@harpun Zwei Mal in den letzten 2 Jahren. Als ich und das Team, mit dem ich an einem Projekt gearbeitet habe, beschlossen, von MySQL oder PostgreSQL zu MongoDB zu wechseln, um zu Node.js zu wechseln und toten Sperren auszuweichen und Objekte stattdessen direkt als Aggregate zu speichern.

— Andy

Es gibt eine andere Option als nur den direkten Zugriff auf db. Die "Mediator-API" muss kein HTTP verwenden, daher muss der HTTP-Server überhaupt nicht beteiligt sein. Es kann sich nur um eine API auf Codeebene handeln. Eine andere Frage ist, vorausgesetzt, Sie sind mit der Geschwindigkeit Ihrer Programmiersprache nicht zufrieden, ob API (REST-Zugriff) mit einer anderen Sprache / Plattform als Ihrer Geschäftslogik geschrieben werden soll ...

— Forsberg

Hier ist meine Meinung zu diesem Thema: Sie haben die richtige Idee, einen Webservice nutzen zu wollen, aber Sie planen möglicherweise, die falsche Technologie zu verwenden.

Wenn Sie REST sagen, gehe ich davon aus, dass Sie über Asp.Net WebApi sprechen. Das ist die falsche Technologie für Intranetanwendungen. REST & WebApi sind fantastisch, verstehen Sie mich nicht falsch, aber für jede Art von interner Anwendung sind WCF-Webdienste meiner bescheidenen Meinung nach der richtige Weg. Sie ermöglichen es dem Client, wie eine Klassenbibliothek auf den Service-Endpunkt zu verweisen. Dies bedeutet, dass Sie in Ihrem Desktop-Client nicht mit XML oder JSON arbeiten. Sie arbeiten mit Klassen und Objekten.

Wie auch immer, ja. Du hast die richtige Idee. Wenn sie nicht sicher sind, ob sie einen webbasierten Client benötigen, müssen Sie Ihr System so gestalten, dass es problemlos hinzugefügt werden kann, wenn sie später entscheiden, dass sie es möchten. Es ist viel einfacher, verschiedene Arten von Clients hinzuzufügen, wenn Sie eine serviceorientierte Architektur haben.

— Quietscheentchen
quelle

Es ist dumm, einen Client zu verwenden, um json für Objekte zu deserialisieren. Die Klassen können sogar mithilfe von json2csharp.com automatisch aus dem Beispiel json generiert werden . Es funktioniert sehr gut mit dem http-Client aus dem Nuget-Paket microsoft.aspnet.webapi.client. Ich verspreche, dass Sie schneller wieder im Objektland sind als mit WCF-Client-Referenzen, daher sollte dies nicht der Haupttreiber für die Auswahl von WCF sein.

— Esben Skov Pedersen

@EsbenSkovPedersen gibt es einen Unterschied zwischen dumm einfach und automatisch .

— RubberDuck

Weil es nie Probleme mit WCF gibt? Das kann nicht richtig sein.

— Esben Skov Pedersen

Wer hat jemals gesagt, dass es keine Probleme mit WCF @EsbenSkovPedersen gibt? Ich habe es sicher nicht getan. Jedes Stück Technik hat seine Probleme. Was ist dein Problem?

— RubberDuck

Wenn Sie sagen, es ist einfacher als dumm, implizieren Sie das. Ich habe kein Problem.

— Esben Skov Pedersen

Schauen Sie sich es auf diese Weise, ist es auf jeden Fall ist ein gemeinsames Muster und realistischerweise als beste Praxis beschrieben.

Abhängig von Ihrer Plattform finden Sie möglicherweise Tools, mit denen das Problem fast behoben ist. Microsoft bietet ODATA-Unterstützung für verbundene Apps, mit denen Formulare über Daten hinweg problemlos erstellt werden können, sobald Sie die Lernkurve überschritten haben.

Pragmatischer: Definieren Sie die API, die Sie für Ihre Datenschicht benötigen, in der Desktopanwendung und codieren Sie diese API. Stellen Sie den gesamten Datenbankzugriff hinter diese API - was die Entwicklung im Hinblick auf die Entwicklung der Anwendung tatsächlich verbessert - und dann wird der Speicherort des tatsächlichen Datenbankzugriffscodes weniger wichtig (dieselbe API könnte durch Code implementiert werden, der direkt mit der Datenbank kommuniziert oder durch Code, der indirekt über einen Ruheendpunkt mit der Datenbank kommuniziert). Wenn Sie mit einer direkten Implementierung beginnen, wird die REST-Version im Wesentlichen ein Wrapper um dieselbe API sein, damit Sie nicht zu stark bestraft werden ...

Es ist wahrscheinlich nicht ganz so einfach, wie ich es mir vorstellen würde - aber es ist ein gutes Muster, es gibt Ihnen die Flexibilität, die Sie möglicherweise benötigen, ohne die YAGNI- Route weit zu gehen .

— Murph
quelle