AngularJS-Client-MVC-Muster?

Bis jetzt war ich hauptsächlich mit Struts 2, Spring, JQueryTechnologie - Stack für die Erstellung von Web - Anwendungen. Der Punkt ist, dass der erwähnte Stapel ein serverseitiges MVCMuster verwendet. Die Hauptaufgabe von Webbrowsern beschränkte sich auf einen Anforderungs- / Antwortzyklus (+ clientseitige Validierung). Datenabruf, Geschäftslogik, Verkabelung und Validierung waren hauptsächlich Aufgaben der Serverseite.

Ich habe einige Fragen zum AngularJS- Framework, die von folgenden Zitaten inspiriert wurden, die ich gelesen habe:

Aus dem AngularJS-Tutorial :

Für Angular-Apps empfehlen wir die Verwendung des MVC-Entwurfsmusters (Model-View-Controller), um den Code zu entkoppeln und Bedenken zu trennen.

Aus dem Wikipedia Model-View-Controller :

Model-View-Controller (MVC) ist eine Architektur, die die Darstellung von Informationen von der Interaktion des Benutzers mit dieser trennt. Das Modell besteht aus Anwendungsdaten und Geschäftsregeln , und der Controller vermittelt die Eingabe und konvertiert sie in Befehle für das Modell oder die Ansicht

AngularJS verwendet ein clientseitiges MVCMuster. Ich denke also, es gibt keine andere Möglichkeit, als die Validierungslogik auf irgendeine Weise auch auf der Clientseite einzubeziehen.

Was wäre der beste Weg, um eine robuste AngularJS-Anwendung zu schreiben? MVC auf der Clientseite und eine Art MC (Modell, Controller) auf der Serverseite?

Bedeutet das, dass MODELL und CONTROLLER auf eine Weise dupliziert werden (Client / Server)?

Ich weiß, dass meine Frage irgendwie komisch ist, aber ich denke, der Grund ist, dass ich irgendwie an das traditionelle serverseitige MVC-Muster gewöhnt bin. Ich bin sicher, dass es jemanden gibt, der bereits den gleichen Übergang gemacht hat.

Überhaupt keine seltsame Frage - ich habe versucht, Angular an viele Java-Entwickler zu verkaufen, und sie fragen dies. Ich habe es selbst gefragt, als ich gelernt habe (ich lerne übrigens immer noch)

Wenn Sie eine 'herkömmliche' Java-Webanwendung wie beschrieben und Angular-ize verwenden, müssen Sie zuerst Ihren Server nehmen und ihn zu einer RESTful-API machen. Entfernen Sie die JSPs usw. Dies ist eigentlich der schwierige Teil, IMO, beim Schreiben einer Angular-App - die richtige REST-API. Der Schlüssel für mich, um zu entscheiden, welche Logik benötigt wird, um in den Server zu gelangen, war , ihn als reine API zu betrachten und für den Moment zu vergessen, dass er ein Front-End haben wird .

Diese Frage hat mir wirklich geholfen - wenn jemand versucht, eine bestimmte Ressource zu speichern und diese Ressource keine gültigen Daten enthält, gibt es kein Front-End, das er darüber informiert, trifft er die API direkt, sodass die API sie ablehnen muss. Das Backend ist also für die Tiefenvalidierung verantwortlich. Dies gilt auch für Ihre Geschäftslogik. Angenommen, jemand verwendet nur die API und es wird klar, was Ihr Server tun muss.

Der Server muss auch Daten im (wahrscheinlich) JSON-Format verkaufen (ich verwende Spring MVC + Jackson), sodass er dafür verantwortlich ist, das Modell Angular auszusetzen und mit der Datenbank zu kommunizieren.

Was ist die MVC dann auf der Winkelseite?

• Modell : Die Daten, die von der REST-API stammen. Wenn die API JSON verkauft, sind diese Objekte bereits Javascript-Objekte der 1. Klasse.
• Ansicht : HTML und Anweisungen, wenn Sie das DOM bearbeiten müssen
• Controller : (und benutzerdefinierte Dienste, die Sie aus Ihren Controllern herausgerechnet haben.)
  • Fragt die REST-API ab und legt fest, was für die Ansicht im Bereich $ erforderlich ist
  • Bietet Rückrufe für Anweisungen, um auf Ereignisse zu reagieren, für die möglicherweise Rückrufe an den Server erforderlich sind.
  • Validierung: normalerweise über einen Rückruf an eine Direktive. Überlappt wahrscheinlich einen Teil der Validierung, die Sie bereits in den Server eingegeben haben , aber Sie möchten nicht, dass Ihr Benutzer darauf wartet, dass der Server alles validiert. Der Client sollte etwas über die Validierung wissen , um dem Benutzer sofortiges Feedback zu geben.
  • Geschäftslogik: So ziemlich die gleiche Geschichte wie die Validierung.

Aber warum die Verdoppelung der Logik im Client und im Server? Meistens, weil Sie nicht eine App schreiben, schreiben Sie zwei unabhängige Dinge:

1. Eine REST-API, die robust und ohne Frontend verwendbar sein muss
2. Eine GUI, die einem Benutzer sofortiges Feedback geben und nicht unbedingt auf einen Server warten muss.

Also, kurze Antwort - machen Sie die REST-API richtig, indem Sie vergessen, dass es eine Benutzeroberfläche geben wird, und was in Angular geht, wird viel klarer.

Ich denke, der Begriff "Geschäftslogik" ist hier etwas falsch. Das "Geschäft" einer clientseitigen App ist das Geschäft mit der Benutzeroberfläche. Es werden keine Dinge wie Sicherheitsregeln und proprietäre Logik oder anderes sensibles geistiges Eigentum sein.

In Angular ist die Division also (allgemein):

• Controller (Controller): Zum Bearbeiten der Daten (Bereich) hinter Ihrer Benutzeroberfläche.
• Anweisungen : zum Einrichten des DOM für die Kommunikation mit dem Controller über den Bereich und zum Manipulieren des DOM.
• Vorlagen (Ansicht): Zum Zuweisen von Anweisungen zu Elementen des DOM.
• Scope (Modell oder Ansichtsmodell) , um Daten zwischen allen Teilen des Systems trägt.
• Dienste : Injizierbare, wiederverwendbare Codebits. Normalerweise für Abhängigkeiten wie den Umgang mit Ajax, Cookies oder anderen E / A.

Es ist wirklich fast MVVM und nicht MVC.

Was Ihre "Geschäfts" -Logik oder -Regeln betrifft ... alles, was Sicherheit erfordert, muss immer auf Serverebene gesichert werden.

Es ist wichtig zu verstehen, dass in einigen Versionen des MVC-Musters sowohl die Daten als auch die Logik, die die Daten manipuliert , in der "Modell" -Schicht liegen (wobei die "Controller" -Schicht nichts anderes als Bindung ausführt). In AngularJS befinden sich jedoch nur die Daten ($ scope) in der Ebene "model", während sich die Logik, die die Daten manipuliert ($ scope), in der Ebene "controller" befindet.

Ich liebe, was @Roy TrueLove sagt. Aber lassen Sie mich sagen, dass dies die ultimative Art ist, Angularjs zu verwenden. Natürlich müssen Sie lernen, Ihre Anwendungen auf diese Weise auszuführen, wenn Sie den größtmöglichen Nutzen aus Angular ziehen möchten. Ich bete, eines Tages dort zu sein.

In der Zwischenzeit, während Ihres Lernens und während Ihres Übergangs zur vollständigen Verwendung von AngularJs als Hauptmethode für Ihre Kunden, können Sie es hier und da für eine kleine Mission verwenden und sich allmählich daran und an seine Vorgehensweise gewöhnen Denken.

Ich ermutige, es allmählich anzunehmen und langsam zu gehen, aber sicher, ich garantiere, sicher.

Angularjs wurde entwickelt, um diesem Ansatz zu dienen, da es sowohl bei der kleinsten als auch bei der größten Aufgabe arbeiten kann. Zum Beispiel habe ich zum ersten Mal Angular verwendet, um Namen anzuzeigen, während der Benutzer IDs eingibt.

Ich stimme den Antworten hier zu. Noch ein paar Kommentare. Wenn Sie eine Bewerbung schreiben, müssen Sie sich zunächst auf die Problemdomäne konzentrieren. Und erstellen Sie ein Softwaremodell für ein echtes Geschäft. Wenn es sich bei Ihrer Problemdomäne beispielsweise um einen Einkauf handelt, können einige der zu modellierenden Anforderungen Folgendes umfassen:

• Die Kreditkarte sollte gültig sein.
• Wenn Sie mit einer Kreditkarte der Marke X bezahlen, erhalten Sie 10% Rabatt.
• Der Einkaufswagen sollte mindestens einen Artikel enthalten, um die Kaufabwicklung durchzuführen
• Die Artikel müssen vorrätig sein, bevor Benutzer sie in den Warenkorb legen können

Die Implementierung dieser Anforderungen modelliert Ihre Problemdomäne. Dies ist Ihre Geschäftslogik.

Angular ist ein Frontend-Framework und ein Toolkit. Es ist ein Web- Frontend. Wenn Sie dies in einem Web-Frontend implementieren, verpassen Sie die Möglichkeit, Ihr Modell von einem anderen Frontend oder einer anderen Benutzeroberfläche wie einer mobilen oder einer Desktop-Anwendung aus wiederzuverwenden. Idealerweise muss Ihre Geschäftslogikimplementierung von jedem Benutzeroberflächen-Framework und auch von jedem dauerhaften Framework entkoppelt werden. Dann haben Sie Ihre Schnittstellenobjekte, die sich mit Problemen der Benutzeroberfläche befassen und mit Ihren Geschäftslogikobjekten kommunizieren. Dies kann ein Spring MVC-Controller und / oder ein Angular-Controller oder -Dienst sein.

Es gibt eine Beispielanwendung, die Sie sich ansehen können und die den hier genannten Prinzipien folgt.

Ich habe anscheinend auch diese Frage, da einige Unternehmen nur nach neuen Technologien suchen - "Ich möchte Cloud ... warte, ich möchte Leichtgewicht". Es ist schwer zu rechtfertigen, ob es den Wechsel zu einem leichteren Framework verdient.

Ich entwickle ständig Webanwendungen mit Spring / JBoss Seam / JSF und auf MVC Framework. Die meiste Zeit befinden sich Java-Skripte für die Validierungen der Präsentationsschicht, und die Hauptaktionsklassen / -entitäten und die Geschäftslogik befinden sich im Java-Code. Nach einigen grundlegenden praktischen Übungen zu Angular begann ich zu verstehen, was sie mit MVC meinten, als sie eine weitere Ebene auf der Präsentationsebene abstrahierten, auf der wir unsere eigenen Ansichten und Controller im Frontend haben können. Um Ihre Frage zu beantworten, legen Sie sie wie jeder Kommentar am besten auf die Präsentationsebene.

Aus Sicherheitsgründen glaube ich, dass auf der Serverseite schwere oder sensible Geschäftsregeln gelten sollten, da wir sie nicht der Welt zugänglich machen wollen. Wenn die Geschäftslogik schlecht entwickelt ist, kann man die Schwachstelle in unserem Code leicht finden und ausnutzen.

Hier ist mein Gedanke für Framework wie Angular ist wie ein kleiner Shop / SOHO-Abwicklungskunde, und sie haben ein paar Leute und sind wirklich effizient und schnell. Sie sind gut für Kunden geeignet, die geschäftlich tätig sind und Waren effizient liefern / empfangen (REST, JSON). Sie haben bestimmte Rollen und Aufgaben, aber einige Mitarbeiter führen mehr als nur Aufgaben aus. Der Laden ist auch anfällig für Diebe oder Räuber, da sie normalerweise keine große Sicherheit betonen.

Stellen Sie sich für ein serverseitiges Framework wie Spring / Struts 2 ein modernes Unternehmen (CMM Level 5) mit unterschiedlichen Managementebenen vor, das in der Lage ist, größere Geschäfte (Batch-Jobs, Webdienste, Unternehmensbus) abzuwickeln. Sie kümmern sich zwar um Kunden, gehen aber nicht direkt über Makler oder sogar Einzelhandelsgeschäfte. In Bezug auf die Sicherheit ist ein Unternehmen robuster, und häufig werden Wertpapiere an der Haustür oder wichtige Informationen in einem Safe geschützt (Verschlüsselung / Anmeldung).

Mein Ansatz ist immer der Bottom-up-Ansatz. Ausgehend vom Datenbankdesign mit ordnungsgemäß erstellten / zugehörigen Tabellen und gespeicherten Prozeduren bei Bedarf fügen Sie dann das Entity Framework zur Lösung hinzu oder verwenden Sie ADO.Net, wenn EF keine Option ist. Entwickeln Sie dann die Geschäftslogik und die Modelle, um die Daten in die Datenbank und aus der Datenbank zu holen.

Mit den etablierten Modellen können wir nun zwei Wege gehen: Entwickeln des MVC-Controllers und / oder Entwickeln des WebAPI-Controllers. Beide Controller können auf die Modelle zugreifen. Es geht lediglich darum, die Klassen zu instanziieren und die Methoden aufzurufen.

Sie haben jetzt die Möglichkeit, MVC-Ansichten einzurichten, die vom MVC-Controller gesteuert werden, oder einen völlig separaten Satz von HTML-Seiten oder SPA (Single-Page-Anwendung, die auf NodeJS gehostet wird).

Mit dem vollständig separaten Satz von HTML-Seiten müssen Sie WebAPI-Controller mit den Methoden Get, Post, Put und Delete verwenden und das Token hin und her einschließen, um Ihren Client zu identifizieren und CORS (für Cross Origin Request) zu aktivieren )

Mit MVC Views können Sie Ihre Clients anhand der Controller-Attribute und / oder -Sitzungen identifizieren, ohne sich um CORS kümmern zu müssen. Bei Bedarf können Sie Ihre Ansichten sogar stark typisieren. Wenn Sie eine Reihe von UI-Entwicklern haben, müssen diese leider an derselben MVC-Lösung arbeiten.

In beiden Fällen können Sie AngularJS verwenden, um Daten von / zu den Controllern hin und her zu transportieren.

Meiner Meinung nach ist das Konzept des AngularJS-Controllers nicht dasselbe wie beim C # MVC- oder C # WebAPI-Controller. AngularJS-Controller enthalten die gesamte Javascript-Logik sowie die Aufrufe von Endpunkten über die "ApiFactory", während C # -Controller nichts anderes als Endpunkte auf der Serverseite sind, die UI-Anforderungen akzeptieren und darauf reagieren.