Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    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.


  • #2
    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 before you start to write code!
    2. Discuss and review it together with experts!
    3. Choose good tools (-> Adventure PHP Framework (APF))!
    4. Write clean and reusable software only!
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Kommentar


    • #3
      Was sollte das Model darüber wissen, wie die Daten übertragen werden?
      --

      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


      --

      Kommentar


      • #4
        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 before you start to write code!
        2. Discuss and review it together with experts!
        3. Choose good tools (-> Adventure PHP Framework (APF))!
        4. Write clean and reusable software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


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

          Kommentar


          • #6
            Zitat von dr.e. Beitrag anzeigen
            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.
            Meinungen, die ich geäußert habe, sind nicht notwendigerweise meine eigenen. Abweichungen von der deutschen Rechtschreibung unterliegen dem Urheberrecht, dürfen aber unter den Bedingungen von verwendet werden

            Kommentar


            • #7
              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 before you start to write code!
              2. Discuss and review it together with experts!
              3. Choose good tools (-> Adventure PHP Framework (APF))!
              4. Write clean and reusable software only!
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

              Kommentar


              • #8
                Zitat von dr.e. Beitrag anzeigen
                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.

                Zitat von dr.e. Beitrag anzeigen
                Technisch ist eine API nichts anderes als ein exterene Form der Business-Schicht.
                Und wo machst du dann Sitzungsverwaltung und Autorisierung?
                Meinungen, die ich geäußert habe, sind nicht notwendigerweise meine eigenen. Abweichungen von der deutschen Rechtschreibung unterliegen dem Urheberrecht, dürfen aber unter den Bedingungen von verwendet werden

                Kommentar


                • #9
                  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 ???
                  Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                  Kommentar


                  • #10
                    Dort wo er auch bei anderen Webanwendungen ist. Es geht hier nicht um beliebige APIs, sondern um Webservices.
                    Meinungen, die ich geäußert habe, sind nicht notwendigerweise meine eigenen. Abweichungen von der deutschen Rechtschreibung unterliegen dem Urheberrecht, dürfen aber unter den Bedingungen von verwendet werden

                    Kommentar


                    • #11
                      wo denn ?

                      Kannst nicht vernünftig antworten ?

                      Bei einer API gibt es keine View.
                      Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                      Kommentar


                      • #12
                        Zitat von Koala Beitrag anzeigen
                        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.
                        Meinungen, die ich geäußert habe, sind nicht notwendigerweise meine eigenen. Abweichungen von der deutschen Rechtschreibung unterliegen dem Urheberrecht, dürfen aber unter den Bedingungen von verwendet werden

                        Kommentar


                        • #13
                          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.

                          Kommentar


                          • #14
                            Zitat von Flor1an Beitrag anzeigen
                            Je nach dem was für ein Format genutzt wird (XML/JSON etc) wird nur sowas ausgegeben, ...
                            Das macht der View.

                            Zitat von Flor1an Beitrag anzeigen
                            ... dafür braucht es nicht wirklich eine komplette View Komponente.
                            Nö, hilft aber.
                            Meinungen, die ich geäußert habe, sind nicht notwendigerweise meine eigenen. Abweichungen von der deutschen Rechtschreibung unterliegen dem Urheberrecht, dürfen aber unter den Bedingungen von verwendet werden

                            Kommentar


                            • #15
                              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.
                              Viele Grüße,
                              Dr.E.

                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                              1. Think about software design before you start to write code!
                              2. Discuss and review it together with experts!
                              3. Choose good tools (-> Adventure PHP Framework (APF))!
                              4. Write clean and reusable software only!
                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                              Kommentar

                              Lädt...
                              X