[MVC] Daten verschlüsseln & entschlüsseln im Controller oder Model

[Forumsgast]

Ich schreibe momentan an einem Webservice, der auf dem MVC-Modell basiert. Nun werden die Infos zwischen Programm und Webservice in verschlüsselter Form übertragen. Nun muss ich diese Infos verschlüsseln bzw. entschlüsseln. Nun bin ich momentan am überlegen, wo man diese Logik unterbringt im Controller oder im Model.

[Forumsgast]

Hallo singu,

warum nutzt du das MVC-Pattern für einen Webservice? Das macht für mich absolut keinen Sinn. Für mich sind hier in erster Linie andere Pattern relevant.

[Forumsgast]

Was sollte das Model darüber wissen, wie die Daten übertragen werden?

[Forumsgast]

Auch wenn deine Frage rhetorischer Natur ist: nichts!

Ich würde für externe Schnittstellen immer mit Input- und Output-Filtern arbeiten, die sich um den verschlüsselten Transport kümmert und bei einem Request die Eingabe in ein DTO oder Domänen-Objekt mappt um über einen Dispatcher an den relevanten Service zu geben (Command Pattern).

[Forumsgast]

Ein Großteil des Webservice ist bereits mit dem MVC-Model programmiert. Es geht jetzt nur noch um die Daten-Verschlüsselung

[Forumsgast]

warum nutzt du das MVC-Pattern für einen Webservice? Das macht für mich absolut keinen Sinn.

Der Nutzer eines Webservices benötigt eine Schnittstelle zum Anwendungskern genauso wie ein Mensch der den Anwedungskern über eine HTML-Seite steuert.

[Forumsgast]

Lies dir mal die Rahmenbedingungen des MVC-Pattern durch. Für eine API ist das definitiv falsch. Hier ist die Präsentation zweitrangig, die Business-Logik steht im Vordergrund. Technisch ist eine API nichts anderes als ein exterene Form der Business-Schicht.

[Forumsgast]

Lies dir mal die Rahmenbedingungen des MVC-Pattern durch.

Nein!!!1 Immerhin bist Du es, der MVC nicht richtig verstanden hat. Ich weiß das ja schon alles, sogar sehr sehr gut!!!1

OK, Spaß beseite. Welche Rahmenbedingungen meinst du konkret? Wie ich das sehe steht jemand der einen Webservice anbietet vor den gleichen Problemen wie jemand, der eine Webanwendung ohne Webservice anbietet:

• Eingehende Nachrichten sind nicht vertrauenswürdig.
• Das verwendete Protokoll ist zustandslos.
• Abhängig von der ankommenden Anfrage muss eine passende Antwort generiert werden.
• Nicht jeder darf Domänenobjekte auf beliebige Art manipulieren.

Ich sehe bis jetzt keinen Grund, warum MVC für Webseiten geeignet, aber für Webservices ungeeignet sein soll.

Technisch ist eine API nichts anderes als ein exterene Form der Business-Schicht.

Und wo machst du dann Sitzungsverwaltung und Autorisierung?

[Forumsgast]

Ich sehe bis jetzt keinen Grund, warum MVC für Webseiten geeignet, aber für Webservices ungeeignet sein soll.

wo ist denn bei einer API die View ???

[Forumsgast]

Dort wo er auch bei anderen Webanwendungen ist. Es geht hier nicht um beliebige APIs, sondern um Webservices.

[Forumsgast]

wo denn ?

Kannst nicht vernünftig antworten ?

Bei einer API gibt es keine View.

[Forumsgast]

Kannst nicht vernünftig antworten ?

Normalerweise schon, aber es ist sehr schwieg, eine Antwort viel vernünftiger zu gestalten als die Frage die sie beantworten soll. Vielleicht bekomme ich es besser hin, wenn du mir sagst, was du an meinem vorletzten Beitrag nicht verstanden hast oder womit du in meinem vorletzen Beitrag nicht einverstanden bist.

[Forumsgast]

Ich wüsste auch nicht wo sich bei nem Webservice nen View versteckt. Je nach dem was für ein Format genutzt wird (XML/JSON etc) wird nur sowas ausgegeben, dafür braucht es nicht wirklich eine komplette View Komponente.

[Forumsgast]

Je nach dem was für ein Format genutzt wird (XML/JSON etc) wird nur sowas ausgegeben, ...

Das macht der View.

... dafür braucht es nicht wirklich eine komplette View Komponente.

Nö, hilft aber.

[Forumsgast]

Hallo momomamu,

wenn du das MVC-Pattern unbedingt in diesen Anwendungsfall pressen möchtest, bist du herzlich eingeladen das zu tun. Bei einer API gilt es jedoch, einen Business-Prozess nach aussen zu repräsentieren. Die Aktionen werden hier in aller Regel durch die Business-komponenten repräsentiert, die mit Domänen-Objekten arbeiten. Hier gibt es keinen Controller im klassichen MVC-Gedanken. Weiterhin ist das Model in einer API einfach ein DTO/Domänen-Objekt, das durch ein Ausgabe-Format repräsentiert wird. Da die Transformation i.d.R. sehr einfach gestrickt ist - z.B. JSON - ist es nicht notwendig einen Controller MVC-einzusetzen. Im Vordergrund einer API stehen weiterhin die Kommandos, die du aufrufen kannst - also das command pattern.

Ich gehe daher davon aus, dass MVC - weil es ein Pattern der Präsentations-Schicht ist - in einer Business-Schicht-getriebenen komponente nichts zu suchen hat.

Und wo machst du dann Sitzungsverwaltung und Autorisierung?

Was hat das mit pro/contra MVC zu tun? Diese Elemente löst du zentral über einen Wrapper um deinen eigentlichen Webservice-Kern, sprich ein Wrapper um die Business-Komponenten.