Sollten wir die Web-API von der MVC-Anwendung in derselben Lösung aufrufen?

33

Ich arbeite an einem Projekt in MVC mit einer mobilen Anwendung, sodass klar ist, dass wir die Web-API verwenden müssen, damit sie in einer mobilen Anwendung verwendet werden kann.

Nach dem Erstellen der API, als wir mit der Entwicklung der Website begannen, waren wir verwirrt und diskutierten, ob die API oder der direkte Zugriff auf das Business-Objekt verwendet werden soll. Und wir waren der Meinung, dass erfahrene Entwickler die Web-API nutzen sollten, anstatt Business-Objekte direkt zu verwenden.

Ich habe Verwirrung in Bezug auf diese Lösungsstruktur.

1) Warum sollten wir die Web-API verwenden und eine HTTP-Anfrage (die zeitaufwendig ist) stellen, um Daten anstelle von Geschäftsobjekten, die sich in derselben Lösung befinden, direkt abzurufen oder abzulegen.

2) Nachdem sie Argumente hatten, sagten sie, was passiert, wenn der Client API und Web auf einem anderen Cloud-Server hosten und die Skalierung nur auf API anwenden möchte oder möglicherweise eine andere URL für den Zugriff auf API und Web haben möchte (was logisch ist). Sollen wir in diesem Fall die Web-API von der MVC-Anwendung in derselben Lösung aufrufen?

3) Wenn wir API und Web auf einem anderen Hosting hosten, bedeutet dies, dass unser Web WebClient verwendet und bei jeder Navigation ein HTTP-Aufruf erfolgt. Ist es richtig?

4) Wenn wir ein Geschäftsobjekt aus API und Webhosting auf einem anderen Server erstellen, muss bei einer Änderung in BL die Build auf beiden Servern aktualisiert werden.

5) Oder wir sollten nur ein Projekt für die API erstellen und Ansichten oder HTML-Seiten hinzufügen, um die Webschnittstelle zu entwickeln, damit wir die API direkt von Ajax aus aufrufen können.

Nach meinem Wissen ist # 5 die beste Lösung oder API ist nur für den Zugriff von Drittanbietern. Wenn sich DB, EF, Datenschicht und Geschäftsschicht in derselben Lösung befinden, sollten wir keine API verwenden, um HTTP-Aufrufe zu tätigen und direkt auf das Geschäftsobjekt zuzugreifen. (Korrigieren Sie mich, wenn ich falsch liege.) API wird benötigt, wenn eine mobile Anwendung oder ein Desktop oder eine andere Person auf die Anwendung zugreifen möchten, damit wir dasselbe Repository und dieselbe Datenschicht haben können.

In meinem Szenario muss eine API erstellt werden, da wir auch eine mobile Anwendung haben. Auf der Seite der Projekt-API haben wir die Business-Schicht (separates Projekt) und die Business-Schicht die Kommunikation mit der Datenzugriffsschicht (separates Projekt) aufgerufen. Meine Frage ist also, ob wir unsere API und das Web auf verschiedenen Servern hosten. Das Aufrufen der API, bei der es sich um eine HTTP-Anforderung handelt, dauert möglicherweise länger als die Verwendung der Methode aus der Business-Schicht, wenn wir das Projekt erstellen, und wir haben die DLL der Business-Schicht. Im API-Controller konvertieren wir einfach die Ausgabe unseres Geschäfts in das json-Format.

Ich habe im Internet gesucht, aber keine überzeugende Antwort erhalten. Ich habe einen Blog gefunden, in dem http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx denselben Punkt behandelt In diesem Blog ist meine Frage, warum wir Szenario # 3 betrachten müssen?

Update: Wir können verschiedene API-Projekte und MVC-Projekte haben und APIs über das Web mit jvascript aufrufen oder MVVM-Muster verwenden.

Ruchir Shah
quelle
MVVM oder MVC mit Ansichtsmodellen?
Andrew Hoffman
Wir verwenden MVC
Ruchir Shah
Ok dann, dann gibt es wirklich keine richtige Antwort. Es hat Vorteile, Ihre API nur dann aufzurufen, wenn es um die Verbesserung ihrer Qualität geht. (Essen Sie Ihr eigenes Hundefutter.) Das Tätigen von Inproc-Anrufen anstelle von Anrufen über Dienste hat auch Leistungsvorteile.
Andrew Hoffman
Google ging diese Frage einmal durch. Ihre Produkte sind sowohl Dienstleistungen als auch Websites. Ich glaube, sie haben beschlossen, dass ihre Websites ihre eigenen Dienste nutzen.
Andrew Hoffman
2
Ja. programmers.stackexchange.com/questions/148556/… und stackoverflow.com/questions/3590561/… sind gute Ressourcen. Manche tun es, manche nicht. Kein richtiger "richtiger" Weg.
Andrew Hoffman

Antworten:

37

Gute Frage! Ich bin immer auf der Suche nach einer besseren Möglichkeit, meine Projekte zu strukturieren. Jeder Punkt, den Sie ansprechen, hat seine Berechtigung und ich habe verschiedene Lösungsstrukturen untersucht. Ich stimme den meisten Kommentaren hier zu: Es gibt keine perfekte Lösung. Ein paar Fragen, die Sie sich bei solchen Problemen stellen sollten: Wie komplex ist diese Anwendung? Mit wie vielen Systemen muss ich mich integrieren - oder mit wie vielen Systemen muss ich mich in dieses System integrieren? Wie viele Tests plane ich? Gibt es ein separates Design- / UI-Team? Müssen wir skalieren? Was macht eine Sitzung aus?

Schauen wir uns ein paar Szenarien und Möglichkeiten an, wie man mit ein wenig cleverer Technik die Dinge wirklich zum Knallen bringt (und einige Tricks, um die Dinge ein bisschen einfacher zu machen).

Hosten von API und Website im selben Projekt
In diesem Fall verfügen Sie möglicherweise über eine einzige Lösung mit null oder mehr Business-Layer-Projekten und einem einzigen hybriden MVC / WebAPI-Projekt (sowie anderen Projekten - Dienstprogramm usw.).


Alles für Profis ist an einem Ort. Komplizierte Nachrichten (HttpClient-Aufrufe) müssen nicht weiter bearbeitet werden. Sie können den Status einer gemeinsamen Sitzung (Client und Server über Cookies, InProc / OutOfProc-Sitzung usw.), Verbindungspooling, gemeinsame Logik usw. festlegen Einfacher kann die Bereitstellung nicht sein.

Con's
Alles ist an einem Ort .. Dies ist wahrscheinlich die monolithischste Struktur möglich. Es gibt keine klar definierten Schnittstellen zwischen Ihren Ebenen. Sie haben eine hohe Kohäsion . Faule Entwickler vermeiden Schnittstellen, wenn sie sich mit dieser Art von Architektur befassen, was das Testen sehr schwierig macht. Das Skalieren / Zusammenfinden der Anwendung wird schwierig sein.

Verwendung
Ich würde diese Projektstruktur für eine einmalige, interne oder einfache Anwendung verwenden. Aufbau eines schnellen Systems zur Verfolgung der Anmeldung zum Basketballcamp bei der örtlichen Y? Das ist deine Architektur!

WebAPI und Website in verschiedenen Projekten
Ich bevorzuge diesen Fall. Sie haben eine einzige Lösung mit einem (oder mehreren) MVC-Projekt (en) und einem WebAPI-Projekt.


Modularisierung für Profis! Lose Kopplung! Jedes Projekt kann einzeln ausgeführt, separat getestet und unterschiedlich verwaltet werden. Auf diese Weise können Sie verschiedene Caching-Strategien je nach Ihren Anforderungen einfacher implementieren. Indem Sie feste Grenzen zwischen Ihren verschiedenen Systemen einhalten, können Sie leichter Verträge abschließen, die es Ihnen ermöglichen, bestimmte Verwendungsmuster durchzusetzen und mögliche Reibungsverluste zu verringern (sprich: weniger Fehler mit weniger Möglichkeiten, die API zu missbrauchen). Das Skalieren ist etwas einfacher, da Sie nur die Bits skalieren müssen, die eine hohe Last aufweisen. Die Integration wird auch etwas einfacher, da Sie von Anfang an eine Vorstellung davon haben müssen, wie Ihre API aussehen wird.

Die
Wartung von Con ist etwas schwieriger. Mehrere Projekte bedeuten, dass Sie Projekt- / Featurebesitzer benötigen, um Zusammenführungen, Verträge (Schnittstellen), Bereitstellungen usw. im Auge zu behalten. Code-Wartung, technische Verschuldung , Fehlerverfolgung und Statusverwaltung - all dies sind Probleme, die möglicherweise auf einer anderen Basis implementiert werden müssen auf Ihre Bedürfnisse. Diese Art von Anwendungen erfordert auch die meiste Planung und Kuratierung, wenn sie wachsen.

Verwendung
Erstellen einer Anwendung, die 100 Benutzer heute und 100.000 nächste Woche / Monat haben könnte? Muss die Anwendung Benachrichtigungen senden, komplexe Workflows verwalten und über mehrere Schnittstellen verfügen (Web + Mobile App + SharePoint)? Sie haben viel Zeit und lieben es, über 5000 Puzzleteile am Wochenende zu lösen? Dies ist die Architektur für Sie!

Tipps
Nachdem ich das Obige skizziert habe, kann ich verstehen, wie Ihr nächstes Projekt ein bisschen entmutigend aussehen könnte. Keine Sorge, hier sind ein paar Tricks, die ich im Laufe der Jahre gelernt habe.

  1. Versuchen Sie, zustandslose Sitzungen zu verwenden. Auf kleineren Systemen kann dies bedeuten, dass ein verschlüsseltes Cookie gespeichert wird, das mindestens die interne ID des aktuellen Benutzers und eine Zeitüberschreitung enthält. Bei größeren Systemen muss möglicherweise ein verschlüsseltes Cookie mit einer einfachen Sitzungs-ID gespeichert werden, die aus einem Datenspeicher abgerufen werden kann (Redis, Tabellenspeicher, DHT usw.). Wenn Sie genügend Informationen speichern können, müssen Sie nicht auf die Hauptdatenbank zugreifen Bei jeder Anfrage sind Sie dann an einem guten Ort - aber versuchen Sie, Cookies unter 1 KB zu halten.
  2. Beachten Sie, dass es wahrscheinlich mehr als ein Modell geben wird. Versuchen Sie, in Modellen und Projektionen zu denken (die Links, die ich hier gefunden habe, waren ... nicht gut ... Denken Sie: Die Inventarposition eines Mannes ist die Bestellposition eines anderen Mannes - dieselbe grundlegende Struktur, aber unterschiedliche Ansichten). Einige Projekte haben für jede logische / konzeptionelle Grenze ein anderes Modell (dh die Verwendung eines bestimmten Modells für die Kommunikation mit einer bestimmten API.
  3. API's überall! Jedes Mal, wenn ein Objekt / eine Klasse / eine Struktur Daten oder Verhalten aufdeckt, richten Sie eine API ein. Beachten Sie, wie andere Entitäten oder Abhängigkeiten diese API verwenden. Überlegen Sie, wie Sie diese API testen könnten. Überlegen Sie, was möglicherweise mit dieser API kommuniziert (andere Objekte über Code? Andere Systeme über ein Protokoll?) Und wie diese Daten verfügbar gemacht werden (stark typisiert? JSON? * Cough * XML?).
  4. Bauen Sie für das, was Sie haben, und nicht für das, was Sie sich in zwei Jahren vorstellen. Eine andere Antwort bezieht sich auf YAGNI - sie sind absolut korrekt! Das Lösen von imaginären Problemen macht Ihre Deadline imaginär. Setzen Sie sich solide Ziele für Ihre Iterationen und erfüllen Sie diese. Bereitstellen! Ein Projekt in der Entwicklung ist ein Projekt mit nur einem Benutzer - Sie!
  5. YMMV (Ihr Kilometerstand kann variieren ). Hier gibt es nur ein Absolut: Es gibt ein Problem, Sie entwickeln eine Lösung. Alles andere liegt komplett in der Luft. Beide oben genannten Lösungen können zu einem wilden Erfolg werden - und zu einem Misserfolg beim Saugen. Es liegt ganz bei Ihnen, Ihren Werkzeugen und wie Sie sie verwenden. Treten Sie leicht, Mitentwickler!
Bobby D
quelle
2
Gute Antwort! Ich wünschte, ich könnte dir etwas für dein Schreiben verleihen, aber da mir nichts einfällt, folge ich einfach deinem Twitter. : P
Dan
"stark getippt? JSON? * hust * XML" was fehlt mir?
Alexander Derck
1
@AlexanderDerck Ich erwähne drei verschiedene Formatierungsoptionen (obwohl es noch mehr gibt). Der "Witz" ist, dass XML schwierig zu bearbeiten ist und oftmals einen erheblichen Mehraufwand verursacht (Serialisierung / Deserialisierung). Das soll nicht heißen, dass es manchmal keine Notwendigkeit gibt (besonders wenn man mit externen Gruppen arbeitet).
Bobby D
6

Der direkte Zugriff auf Ihre Geschäftsobjekte (ich nehme an, Sie meinen in Ihrem Controller) ist schneller und einfacher.

Was ist, wenn der Client API und Web auf einem anderen Cloud-Server hosten und die Skalierung nur auf der API anwenden möchte?

Dann musst du sie separat hosten ... aber das klingt für mich nicht sehr logisch, du würdest sicherlich beides skalieren wollen. Sind Sie sicher, dass Sie diese Anforderung erfüllen müssen? Das klingt nach Overkill. Denken Sie an YAGNI - wenn Sie es nicht brauchen, bauen Sie es nicht. Wenn Sie es brauchen, bauen Sie es.

Wenn ich es wäre, würde ich die Site mit der Technologie erstellen, die am besten zu der Site passt, und wenn (wenn) Sie einen Service benötigen, den andere Leute separat als Build bezeichnen können.

Rocklan
quelle
Ich stimme Ihnen voll und ganz zu, da Skalierung am Ende der Tage wichtig ist und die Trennung von Bedenken für mich von Bedeutung ist. Es ist immer gut daran zu denken, n-Tier-Architekturen als Technologieänderungen zu erstellen, die einfach aktualisiert oder gewartet werden können. Beispielsweise ist das Umwickeln mit Docker-Containern in Zukunft eine weitere Überlegung.
Ishwor Khanal
4

Ich würde sagen; bevorzugen MVC-Aufruf von WebAPI über HTTPClient. Es ist überwältigend, die "Kern-DLL" -Logik zu umgehen, aber der Hauptvorteil besteht darin, dass Ihr Gesamtsystem über einen einzigen Punkt auf Domänenobjekte auf HTTP zugreifen kann Clientseitige Frameworks (AngularJS usw.) ... MVC besser als anderen Client behandeln ... und Ihr Team dazu bringen, APIs gut zu verwalten ...

HALTEN SIE ES EINFACH. Ich hoffe das hilft. Vielen Dank..

Manoj Kumar Bisht
quelle
Ich
bin
Ich habe über meine Situation nachgedacht, in der ich dachte, es wäre eine gute Idee, API von einer eigenen MVC-App aus aufzurufen. Aber ich denke, es unterscheidet sich von dieser und möglicherweise vielen anderen Fragen, die sich auf diesen Aufruf von der Serverlogik beziehen. In meinem Fall rufe ich es tatsächlich aus meiner Sicht auf, in der Vue komplexe Benutzeroberflächen bildet und die Daten an diese API übergibt. Dann wurde mir klar, dass es legitim ist, weil es in meinem Fall tatsächlich von einer Ansicht aus im Vergleich zu serverseitigen Elementen aufruft und alle http-Aufrufe bei der Betrachtung jeglicher Art von Benutzeroberfläche sowieso durchgeführt worden wären - vielleicht noch mehr, wenn ASP-Ansichten erstellt worden wären. Funktioniert jedoch nur in JS-Umgebungen.
Vasily Hall
Das direkte Anzeigen der aufrufenden API ist eine gute Idee. MVC-Ansichten werden jedoch vom Server generiert, sodass Sie auch Daten vom Server verarbeiten können, die für die Serververarbeitung relevanter sind, bevor Sie Teilansichten (Ansichten) ... RESS-Framework (RESS) rendern : Responsive Web Design + Server-seitige Komponenten) .... ABER BEST USE PURE Client Frameworks (Angular / ReactJS), wenn Sie MVC völlig vermeiden können ...
Manoj Kumar Bisht