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.
Ankündigung
Einklappen
Keine Ankündigung bisher.
[MVC] Daten verschlüsseln & entschlüsseln im Controller oder Model
Einklappen
Neue Werbung 2019
Einklappen
X
-
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.Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
Was sollte das Model darüber wissen, wie die Daten übertragen werden?[COLOR="#F5F5FF"]--[/COLOR]
[COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
„Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
[URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
[COLOR="#F5F5FF"]
--[/COLOR]
Kommentar
-
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).Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar
-
Zitat von dr.e. Beitrag anzeigenwarum nutzt du das MVC-Pattern für einen Webservice? Das macht für mich absolut keinen Sinn.
Kommentar
-
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.Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar
-
Zitat von dr.e. Beitrag anzeigenLies dir mal die Rahmenbedingungen des MVC-Pattern durch.
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.
Zitat von dr.e. Beitrag anzeigenTechnisch ist eine API nichts anderes als ein exterene Form der Business-Schicht.
Kommentar
-
Zitat von Koala Beitrag anzeigenKannst nicht vernünftig antworten ?
Kommentar
-
Zitat von Flor1an Beitrag anzeigenJe nach dem was für ein Format genutzt wird (XML/JSON etc) wird nur sowas ausgegeben, ...
Zitat von Flor1an Beitrag anzeigen... dafür braucht es nicht wirklich eine komplette View Komponente.
Kommentar
-
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?Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar
Kommentar