Das Contao Camp 2020 in Hamburg. LEIDER ABGESAGT!
Ergebnis 1 bis 2 von 2

Thema: Best Practices - Namespace für nicht persistente Entities

  1. #1
    Contao-Nutzer Avatar von Jayster
    Registriert seit
    16.06.2014.
    Ort
    München
    Beiträge
    207

    Standard Best Practices - Namespace für nicht persistente Entities

    Mal wieder eine Frage an die Symfony Entwickler hier.

    Ich hab in meinen Applikationen zwei Arten von Entities:

    1. Entities, die in der Datenbank gespeichert werden (Doctrine)
    2. Entities, die nicht gespeicher werden, also nur der Modelierung dienen.

    Bisher hab ich die immer in zwei verschiedenen Namespaces abgelegt, um diesen Unterschied deutlich zu machen. Die aus 1. unter "App/Entity", die aus 2. unter "App/Model".

    Mit dem Namespace von 2. war ich nie ganz glücklich, da das Wort "Model" zu allgemein ist. In meinem aktuellen Projekt überlege ich daher, beide Arten von Entities unter "App/Entity" abzulegen, egal ob sie gespeichert werden oder nicht.

    Wie macht ihr das denn?

    Eine zweite ähnliche Frage habe ich auch. Beim Domain Driven Design gibt es Aggregates, Entities und Value Objects. Bietet es sich dann an, dementsprechend drei Namespaces zu verwenden? Was wäre dann, wenn ein Aggregate in der Datenbank gespeichert werden soll? Muss eine Doctrine Entity zwingend im Namespace "Entity" liegen?

  2. #2
    Contao-Urgestein
    Registriert seit
    29.10.2009.
    Ort
    Magdeburg
    Beiträge
    1.947
    Partner-ID
    626
    User beschenken
    Wunschliste

    Standard

    Grundsätzlich solltest du dich fragen, ob du nach den technischen Notwendigkeiten deine Namespaces / Benennung aufbaust oder dich so nah wie möglich an des Geschäftslogik orientierst. Mit Domain Driven Design hast du dich ja anscheinend schon beschäftigst. Grundsätzlich kannst du Doctrine ORM auch andere Pfade für deine Entitäten mitteilen, der Ordner Entity ist halt im Orm-Bundle vordefiniert und funktioniert ohne weitere Konfiguration. Persönlich bin ich ein Verfechter des Domain Driven Design Ansatzes, also möglichst alles anhand der Businesslogik zu organisieren.

    Klassen einer Todoliste würde ich beispielsweise folgendermaßen organisieren:

    PHP-Code:
    namespace App\Model\TodoList 
    {
        final class 
    Todo {}
        
        final class 
    TodoId implements \App\Common\AggregateRootId {}
        
        final class 
    AssignedUserId implements \App\Common\AggregateRootId {}
        
        final class 
    DueDate {}
        
        interface 
    TodoList {}
    }

    namespace 
    App\Model\Comment 
    {
        final class 
    Comment {}
        
        final class 
    CommentId {}

        interface 
    Comments {}
    }

    namespace 
    App\Doctrine\ORM 
    {
        final class 
    TodoRepository implements \App\Model\TodoList\TodoList {}
        
        final class 
    Comments implements \App\Model\Comment\Comments {}

    Vielleicht hilft dir das weiter. :-)

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •