Ankündigung

Einklappen
Keine Ankündigung bisher.

Buisness-Logic

Einklappen

Neue Werbung 2019

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

  • [Laravel] Buisness-Logic

    Hey,

    ich arbeite jetzt schon eine Weile mit Laravel und fange derzeit ein neues Projekt an. Allerdings muss ich zugeben ich habe meine Business-Logic bislang entweder im Controller oder irgendwo wo es mir grade gepasst hat abgewickelt. Das will ich jetzt ändern. Laravels-Doku gibt mir Leider keinen Hinweis wo genau ich meine Models verstauen soll. Und einen Unterordner "models" im app-Ordner anzulegen finde ich irgendwie "unsauber". Aber vielleicht ist das auch der richtige Weg. Kann mir jemand verraten wo ich meine Logik am besten unterbringe bzw ob Laravel da was spezielles vorsieht?

    Die Jobs/ Events die Laravel anbietet, scheinen mir nicht 100% das zu sein was ich suche, oder ich versteh es einfach nur falsch.

    Danke schon mal

    MfG Tera
    - Laravel

  • #2
    Nach dem MVC Prinzip sitzt das Gehirn des Ganzen doch im Model. Controller und View sind doch nur Knechte, so habe ich es gelernt/gehört

    Kommentar


    • #3
      Ich machs derzeit so, dass ich im unter app/Libs mein Zeug thematisch gruppiert reinpacke.

      bspw

      ./app/Libs/User
      UserRepository.php
      UserWhateverService.php
      UserAnotherService.php

      Ob das jezz das Sinnvollste ist weiss ich auch nicht Hab mich da auch noch nicht so festgelegt.
      Heilung bei codebedingtem Augenkrebs

      Kommentar


      • #4
        Ich hab's so.
        /app/Database/Eloquent // Abstract ( AbstractUser )
        /app/Database/Contract // Interfaces ( UserInterface )
        /app/Database/Models // Models ( User.php )
        /app/Database/Repositories // Repositories ( UserRepository )

        Die Klassenbezeichnungen sind nur Beispiele und müssen in keinem Zusammenhang stehen.
        Github_Cyrix, Laravelgemeinschaft bei php.de,Laravel Chat

        Kommentar


        • #5
          Hab es jetzt ähnlich wie _cyrix_ gelöst:

          app/models/ <- UserModel, BlogModel etc...
          app/repository/ <- UserRepository, BlogRepository etc...
          app/interfaces/ <- iBlogRepository, iUserRepository etc...

          Mein Logik wird vollständig im Repository abgewickelt. Controller und Model übergeben lediglich Daten ans Repository.
          - Laravel

          Kommentar


          • #6
            Ich sehe eigentlich gar kein Problem darin, die Logik in Models und Controllern abzuarbeiten. Die Controller machen die eigentliche manipulation und nutzen dafür bestimmte Funktionen, die von den Models bereits bereitgestellt werden. Wenn ich wirklich alles in den Controller setze, kann es schnell redundant werden und alles in die Models geht vom Prinzip ja schon nicht.
            Fatal Error: Windows wird gestartet

            Wie administriert man ein Netzwerk: Beispiel

            Kommentar


            • #7
              Ich halte Logik im Repo für falsch. Das Repo ist dazu da, Tupel zu manipulieren und Zugriffsübergreifend bereitzustellen. Die Manipulation der Daten muss ausserhalb geschehen.
              [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

              Kommentar


              • #8
                ChristianK

                Wo denn dann? Eigentlich MVC technisch gesehen müsste es im Model stattfinden. Allerdings sehe ich die Models von Laravel eher als Klassen an in denen ich Relationen zu den anderen Tabellen etc definiere und die mir meine Daten geben. Logik hat da meines Erachtens nichts drin zu suchen. Daher habe ich dann ein Repository vorne dran gehängt das dann im Controller aufgerufen wird:

                PHP-Code:

                $this
                ->repro->all(); // Liefert alle Einträge
                $this->repro->edit($request$id); 

                // Method all:
                {
                    
                retrun $this->model->all();
                }

                // Method edit:
                {
                     
                // Validierung der Übergebenen Daten
                     // eventuell noch anderes

                Ist vielleicht ein wenig Mischmasch, aber ich weiß wirklich nicht wo ich die Logik sonst hinsetzen soll. Ich kann schlecht zwei Ordner haben in denen Models drin liegen, nämlich einmal die Models von Laravel und einmal meine. Oder ist das doch der richtige Ansatz? Aber dann ist die Namensgebung scheiße (sorry). Weil wer blickt noch durch wenn ich zwei arten von Models habe?
                - Laravel

                Kommentar


                • #9
                  Zitat von tera3yte Beitrag anzeigen
                  ChristianK

                  Wo denn dann? Eigentlich MVC technisch gesehen müsste es im Model stattfinden. Allerdings sehe ich die Models von Laravel eher als Klassen an in denen ich Relationen zu den anderen Tabellen etc definiere und die mir meine Daten geben. Logik hat da meines Erachtens nichts drin zu suchen.

                  Hierfür sind Service-Klassen gedacht. Diese kapseln die nötige Business-Logik, die unabhängig von dem Controller und unabhängig von der Datenquelle sein sollte. Models sind meiner Meinung nach reine Datenrepräsentationen und sollten zum Datenaustausch genutzt werden. Was der Controller, der Service oder die OR-Schicht daraus macht ist nicht weiter relevant für die Business-Logik. Der Controller beispielsweise sagt dem Service, dass ein UserModel persistiert werden soll. Der Service kennt dann die genauen Bedingungen unter welchen die Persistierung durchgeführt wird, das Model sollte davon keine Kenntnis haben.

                  Kommentar

                  Lädt...
                  X