Ankündigung

Einklappen
Keine Ankündigung bisher.

DTOs bei verschiedenen Anwendungsfällen

Einklappen

Neue Werbung 2019

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

  • DTOs bei verschiedenen Anwendungsfällen

    Ich habe eine App mit verschiedenen Anwendungsfällen (use cases). Jeder dieser Fälle benötigt die Projekt-Entität und, je nachdem, die Kunden-Entität. Diese sind jeweils ein eigenes Aggregat mit Repository. Kann ich diese beide in einem DTO zusammenfassen, oder sollte ein DTO nur 1 Entität spiegeln? Außerdem: werden DTOs nach dem Anwendungsfall benannt, z.B. EmailSubmissionDTO, oder nach den beinhaltenden Objekten/Entitäten?

  • #2
    Ein DTO sollte m.M.n. zur Performancesteigerung führen für z.B. "teure" API oder Service Calls. Von daher: zusammenlegen erscheint legitim.
    Benamung würde ich dann zweckmässigerweise nach dem Anwendungsfall machen, dann erkennt man anhand des Namens bereits den Verwendungskontext.

    Das ist aber nur (m)eine Meinung.
    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    Kommentar


    • #3
      Zitat von lstegelitz Beitrag anzeigen
      Ein DTO sollte m.M.n. zur Performancesteigerung führen
      Ja, ich möchte verhindern, beim Auslesen eines einzelnen Projekt-Attributs gleich das ganze Aggregat laden zu müssen.

      Kommentar


      • #4
        In meinem Template steht dann so etwas:

        PHP-Code:
        $this->DTO->getStatus()->getValueof'ClientEmail' ); 
        Wobei Status ein Wertobjekt bzw. eine Komponente des Projekt-Aggregats ist. Macht das so Sinn, oder gibt es weniger schreibintensive Möglichkeiten, Werte aus einem DTO auszulesen?

        Und sollte man besser einen Assembler für jeden Anwendungsfall haben, oder kann man - bei einem Projekt "normaler" Größe - einen Assembler mit z.B. einer switch() - Weiche und Methoden für die verschiedenen Fälle bauen? Mein aktueller Stand würde so aussehen, aber es ist eigentlich ungewöhnlich, verschiedene Anwendungsfälle in 1 Objekt zu finden:

        PHP-Code:
         class Assembler {

            private 
        $ProjectRepository;
            private 
        $ClientRepository;

            public function 
        __constructProjectRepository $ProjectRepositoryClientRepository $ClientRepository ) {

                
        $this->ProjectRepository $ProjectRepository;
                
        $this->ClientRepository $ClientRepository;

            }

            public function 
        getstring $usecase ) : object {

                switch ( 
        $usecase ) :

                    case 
        'IncomingCallScreen' :

                        return 
        $this->getIncomingCallScreenDTO();

                        break;

                endswitch;


            }

            public function 
        getIncomingCallScreenDTO() : IncomingCallScreenDTO {

                ... 
        etc.

            }

        Kommentar


        • #5
          Außerdem: werden DTOs nach dem Anwendungsfall benannt, z.B. EmailSubmissionDTO, oder nach den beinhaltenden Objekten/Entitäten?
          Kommt darauf an. Ich würde mich nicht darauf verlassen, dass Deine internen Entiäten auch für externe Zugriffe geeignet sind. Man muss es abwägen.

          Ich würde z. B. für schreibende Zugriffe devinitiv extra Entitäten verwenden, z. B. "CreateUserRequest" u. ä.

          Für die Aggregationen gibt es einen Ansatz, bei dem der Requester mit angibt, was er haben möchte. Das gibt es bei GraphQL.

          Kommentar

          Lädt...
          X