Ankündigung

Einklappen
Keine Ankündigung bisher.

Symfony Unterschied zwischen Entity und Repository

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

  • Symfony Unterschied zwischen Entity und Repository

    Moin zusammen,
    kann mir jemand erklären worin genau der Unterschied zwischen Entity und Repository liegt? Kann nicht alles in der Entity stehen? Wofür nutzt man ganz genau was?


  • #2
    Ein Entity repräsentiert einen Eintrag in deiner Datenbank und ist ein reiner DatenContainer ohne Abhängigkeiten. Ein Repository enthält Abfragen. findByName() usw.

    Kommentar


    • #3
      Entity: Stellvertreterobjekt eines Datensatzes in PHP

      Repository: https://de.wikipedia.org/wiki/Reposi...ntwurfsmuster)

      Kommentar


      • #4
        Zitat von Zeichen32 Beitrag anzeigen
        Ein Entity repräsentiert einen Eintrag in deiner Datenbank und ist ein reiner DatenContainer ohne Abhängigkeiten.
        Nicht zwingend repräsentiert ein Entity einen Eintrag in der Datenbank. Und eine Entity hat häufig Abhängigkeiten (z.B. Rolle im User).

        Eine Entity beschreibt in der Regel einen Datensatz in der verwendeten Programmiersprache. Im Bezug auf Datenbanken abstrahieren diese das gesamte Datenmodell auf in der Anwendung nutzbare Objekte.
        "Software is like Sex, it's best if it's free." - Linus Torvalds

        Kommentar


        • #5
          Stell dir vor, du hast eine Kiste mit Ämpfel vor dir Stehen.

          Die Kiste ist Repository
          Ein Apfel ist eine Entity

          Das Repository hällt die Objekte vor, ein Behälter/Lager und du holst dir die Objekte aus dem Repository. Manchmal hast du leere Entities(ohne Kind Elemente), manchmal hast du komplette Entities mit Unterentities (auch Aggregate gennant https://entwickler.de/online/php/ddd...gn-185328.html)

          Je nach dem Welcher UseCase, benötigst du unterschiedliche Repositories die aber letzendlich ähnliche Objekte zurückliefern.

          Als Beispiel

          PHP-Code:
          $products $productRepository->findByGroup('t-shirt'); 
          und

          PHP-Code:
          $products $shoppingHistory->findByUser($user); 
          beim ersten kriegst du nur ein reines Produkt während du bei zweiten vielleicht noch Rechnungsdaten benötigt. Will halt damit sagen, dass du nicht mehrere Repositories ansprechen sollst um dann dein Datensatz zusammen zu bauen, stattdessen machst du ein Konkretes Repository und da drin kannst du auch besser deine JOINS einbauen.
          apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

          Kommentar


          • #6
            @JaMa Er hatte hier ja explizit nach Symfony gefragt, welches Doctrine verwendet. Und da ist es meiner Ansicht nach so. Im allgemeinen Kontext hast du natürlich recht. Mit Abhängigkeiten meinte ich explizit Abhängigkeiten zu anderen Klassen. Bsp. EventEmitter oa.

            Kommentar


            • #7
              Zitat von Zeichen32 Beitrag anzeigen
              @JaMa Er hatte hier ja explizit nach Symfony gefragt, welches Doctrine verwendet. Und da ist es meiner Ansicht nach so.
              Eine Ausnahme dazu stellt imho das Inheritance Mapping dar. Aber das ist meistens die schlechtere Lösung.

              Kommentar


              • #8
                Ich Danke euch allen für eure Erklärungen, ich habe nun den Sinn dahinter besser verstanden.

                Kommentar


                • #9
                  Da es hier zum Thema passt:

                  Definiert ihr die Repositories als Service und ruft sie direkt im Controller oder einer Logikklasse auf oder kapselt ihr sie noch einmal in eine Art DB-Provider-Klasse, in der dann der EntityManager oder die Methoden des Repositories aufgerufen werden?

                  Kommentar


                  • #10
                    Zitat von wario Beitrag anzeigen
                    Da es hier zum Thema passt:

                    Definiert ihr die Repositories als Service und ruft sie direkt im Controller oder einer Logikklasse auf oder kapselt ihr sie noch einmal in eine Art DB-Provider-Klasse, in der dann der EntityManager oder die Methoden des Repositories aufgerufen werden?
                    Das kommt aufs Projekt und die persönliche Präferenz an - beide Varianten sind imho völlig in Ordnung. Die direkte Verwendung der Repositories hat aber den Vorteil, dass man mit einem Blick sieht, welche Datenquellen ein Controller (, Service, whatever..) anspricht.

                    Kommentar

                    Lädt...
                    X