Mit MVC (Model-View-Controller) in einer Client-Server-Architektur

Ich versuche, wählen Sie ein design-Muster für eine Anwendung, die ich entwickle. Die Anwendung ist in Erster Linie basierend auf einer Client-Server-Architektur, wo der Kunde im Grunde liest und schreibt Daten auf den Server; es ist nicht eine Web-Anwendung Die client müssen die software installieren, die ausführbare Datei und dann die Interaktion mit einem GUI, um die Kommunikation mit dem Server (welche Ausgänge auf einem anderen Computer) über ein internet-Protokoll.

Da die Anwendung basiert auf der schwere der Interaktion mit einem GUI, ich dachte über die Verwendung des MVC-design-pattern, die Sache ist die, ich habe Schwierigkeiten, Entscheidung, welches Teil sollte auf dem Server vorhanden sind und welche auf der Client-Seite. In anderen Worten, ist es ok, um die Ansicht (ich.e die Grenze, die GUI-Klassen und Objekte) und die Controller auf der Client-Seite, während die Modell (ich.e die Entity-Objekte) auf der Server-Seite, ist das eine brauchbare oder gültige Anwendung des MVC-pattern ? Werde ich in die richtige Richtung ?
Ist das überhaupt möglich ? Ich meine, können diejenigen, Boundary und Control-Klassen zu betreiben und auszuführen, ohne dass der oder dem Zugriff auf die Model-Klassen auf der gleichen Maschine oder ein Prozess ?

Sollte ich die ganze Sache (Das Modell, View und Controller-Klassen) auf der Client-Seite und dann nur die Kommunikation mit der Server-Datenbank über das Protokoll ?

Anregungen oder Kommentare wäre willkommen.

InformationsquelleAutor hesperus | 2011-10-30

  1. 4

    Gibt es eine Menge von Möglichkeiten der Umsetzung von MVC in einer client-server-Einstellung. Im Allgemeinen, je mehr Dinge du in der client der "reicheren" oder "fetter" Ihre Anwendung wird. Also, wenn Sie entscheiden über die Verwendung von MVC, die eigentliche Frage für Sie ist, dann wird: wie Reich will ich, dass meine Anwendung?

    Können, können Sie auch mehrere Instanzen von MVC zusammen arbeiten, die in einer Anwendung, die verteilt auf client und server.

    Einige der Dinge, würde ich schauen:

    • Netzwerk: Wie viele Daten muss pendelte zwischen client und server? Wie viele Anfragen wird eine Anwendung in der Regel senden? (zu viel kann zu sättigen, die Netzwerk-oder die Ursache für andere Probleme)

    • Reaktionsfähigkeit: höhere Reaktionsfähigkeit kann erfordern, dass man mehr in der client -

    • Sicherheit: alles, was geht über die Leitung möglicherweise weniger sicher

    • Leistung: wenn Sie eine hohe Leistung haben, müssen Sie möglicherweise die Komponenten auf dem server

    • erwartenden Kräfte: Sie entscheiden können, um weitere Komponenten der client-Seite zum auslagern der server, anstelle von clustering Ihrem backend zum Beispiel

    • etc.

    InformationsquelleAutor eljenso

  2. 1

    Ihre Gedanken über die Verwendung von MVC ist ganz richtig. Dies wird Ihnen helfen, de-paar der Dinge, und geben Ihnen mehr Kontrolle über Klassen.

    Ich würde vorschlagen, halten Sie die Ansicht auf der client-Seite. Ich würde immer die controller und model-Klassen auf dem server. Controller ist die Komponente, die ist knifflig. Man kann leicht in Versuchung, es zu halten auf die Kunden, die Gründe legte es auf den server wäre: Interaktionen mit DAOs, Wechselwirkungen mit Modell-Klassen, Fehlerbehandlung und Ablaufsteuerung (Bildschirme/Aktionen).

    Einen controller auf der client-Seite nicht belegen kann, um einfach zu sein zu entwickeln, aber letztlich muss man die änderungen (wie Tastendrücke, Klicks, etc etc) auf den server. Weiter, einen controller auf der client-Seite würde dann langsam beginnen, schieben Sie in Richtung mehr und mehr Klassen auf der client-Seite.

    InformationsquelleAutor Ravi Bhatt

  3. 0

    Nachdem eine Menge von R&D ich fand die beste Leistung die Mehrheit der controller und die view auf dem client, und auch einen kleinen Teil der controller und das Modell auf dem server. Man könnte dann sagen, die Steuerung wurde von split über client-und server - der Vorteil ist, dass, wenn der controller benötigt Vermögenswerte, die sich bereits im Cache auf dem client, es tatsächlich vermeidet, Netzwerk-traffic, das ist wichtig, damit die Dinge schnell laufen. Hier ist ein Beispiel: http://www.youtube.com/watch?v=g73GcQqrDeA

    Grundsätzlich fand ich, dass die Leistung schlecht war, wenn die Verwendung solche Dinge wie server-Seite, template-engines oder alles, was für einen cache-miss aus dem browser, so dass alle html-müssen zu 100% statisch. Mit jQuery nur dann, out of the box, die es bietet wirklich nützliche Veranstaltung verbindlich Einrichtungen, die Sie delegieren können, um eine Controller-Klasse, die auch zwischengespeichert werden an den browser. Am Ende, die nur Daten hin und her ist JSON - nur darauf achten, dass Ihre server sicher, Kodieren/verschlüsseln alle wichtigen Bezeichner, stellen Sie sicher, dass Sie nicht das gleiche auch für den gleichen Benutzer zwischen den Sitzungen usw...

    InformationsquelleAutor Julain

  4. 0

    Kann man nicht wirklich gelten traditionelle MVC-zu-server-client-Architektur. Gründe HIERFÜR sind:

    • Der server und der client hat verschiedene Laufzeiten und APIs.
    • Müssen Sie einige business-Logik auf dem server aus Gründen der Sicherheit, aber es sei denn jeder user-Aktion wird die roundtrip zum server und zurück müssen Sie einige business-Logik auf der client-Seite (denken Sie über die form-Validierung). Im Effekt heißt das, Sie haben die Modell auf beiden.
    • Im traditionellen MVC die - Controller halten eine Referenz auf das Modell. Ein controller auf der client-Seite nicht wirklich halten eine Referenz auf das Modell auf dem server, da die Netzwerk-Fassade.
    • Was mehr ist, in der traditionellen MVC-das model-Schicht hat alle das Modell records. In vielen web-Anwendungen, der client bekommt nur Teilmodell (glaube Seite 1 von 3).
    • Die beiden letzten Punkte auch bedeuten, dass die (Teil -) Modell in Ihrem client ist nicht wirklich Ihr Modell - wenn es zwei Ansichten für das gleiche Modell (glaube eine paginierte Liste der clients, und eine typeahead dropdown-Liste mit remote-Suche auf einem anderen anzeigen) gibt es auch zwei Controller, jeder mit seinem eigenen Modell. So das Modell ist in der Tat eine phantom view-Modell und nicht real Modell.

    Gibt es noch viele weitere Gründe, aber ich denke, die oben veranschaulicht den Punkt.

    Gibt es verschiedene Möglichkeiten, um dies zu bekämpfen, immer etwas sehr nah an MVC einbeziehen können, um eine Modell-proxy auf der client-Seite. Zu den mehr abstrakten/flexibel Befehl-basierte Agenten-Architektur.

    InformationsquelleAutor Izhaki

Schreibe einen Kommentar