Dieses Verfahren ist für PHP-Versionen vor PHP 8.1 gedacht, die den nativen Enum-Typ enthalten. Wir könnten die gleiche Lösung mit wenigen Änderungen mit Enums oder mit einem anderen bestehenden Ansatz behandeln. Viele Projekte verwenden jedoch immer noch PHP 8.0 oder älter und dieser Code ist immer noch nützlich für die Anpassung unserer Enum-Typen in PostgreSQL mit Doctrine und Symfony.

Stell dir vor, du hast einen Typ appointment_status als Enum in deinem alten Datenbankschema wie folgt definiert.

CREATE TYPE public.appointment_status AS ENUM
 ('Open', 'Invited', 'Assigned', 'Unassigned');

Und du verwendest diesen Typ in einer bestimmten Spalte:

CREATE TABLE IF NOT EXISTS public.appointment
  {
 id integer NOT NULL,
 status public.appointment_status NOT NULL DEFAULT 'Open'::public.appointment_status,
 comment character varying(500)
  }

In diesem Artikel erfahren wir also, wie man diese Art von Daten auf einfache Weise handhaben kann.

Erstellen eines abstrakten Enum-Typs

Der erste Schritt ist die Erstellung einer abstrakten Klasse für diese Art von Daten. Mit dieser Abstraktion können wir die Klasse für jedes Enum-Feld wiederverwenden.

schema . ".\"" . $this->getName() . "\""; 
  }  
 
 public function convertToPHPValue($value, AbstractPlatform $platform) 
  {  
 return $value; 
  }  
 
 public function convertToDatabaseValue($value, AbstractPlatform $platform) 
  {  
 if (!in_array($value, $this->getValidValues())) { 
 throw new \InvalidArgumentException("Invalid '".$this->name."' value."); 
  }  
 return $value; 
  }  
 
 public function getName(): string 
  {  
 return $this->name; 
  }  
 
 public function requiresSQLCommentHint(AbstractPlatform $platform): bool 
  {  
 return true; 
  }  
 
 public function getValidValues(): array 
  {  
 return $this->values; 
  }  
 
}  
 

Erstellen des Enum-Typs

Nun musst du den spezifischen Enum-Typ erstellen, der die abstrakte Klasse erweitert:

values = self::$options; 
  }  
 
 public function getValidValues(): array 
  {  
 return self::$options; 
  }  
}  
 

Tipp: Wenn die Liste zu lang ist, kannst du die Klasse in zwei Dateien aufteilen; die Logik auf der einen Seite und die Werte auf der anderen, so erhältst du besser wartbare Klassen

values = CitizenshipEnum::getValues();
  }
 public function getValidValues(): array
  {
 return CitizenshipEnum::getValues();
  }
}
namespace App\Infrastructure\Persistence\Doctrine\DBAL\Enums;
class CitizenshipEnum
{
 protected static array $values = [
 'Ohne Angabe',
 'Afghanistan',
 'Algerien',
 'Andorra',
 'Angola',
 '[....]',
 'Vietnam',
 'Zentralafrikanische Republik',
 'Zypern',
 ];
 public static function getValues(): array
  {
 return self::$values;
  }
}

Definieren als Typ in Doctrine

An diesem Punkt müssen wir Symfony mitteilen, dass wir einen neuen Datentyp haben. Das einzige, was noch aussteht, ist eine Map in Doctrine und wir müssen ihr sagen „Eh, dieser Datentyp ist etwas Besonderes!“. Bearbeite die doctrine.yml und füge diese Zeilen hinzu:

doctrine: 
 dbal: 

 […] 
 mapping_types: 
 appointment_status: appointment_status 

 

 types: 
 appointment_status: App\..\AppointmentStatusType 

 

Mapping Entität mit benutzerdefiniertem Datentyp

Ja! Doctrine kennt jetzt die einzigen zulässigen Werte für den Status. In unserer XML-Datei für das Mapping von Entitäten können wir jetzt verwenden:

<!-- status -->
<field name="status" type="appointment_status" column="status">
    <options>
        <option name="default">Open</option>
    </options>
</field> 

In unserer Entitätsdatei müssen wir „string“ verwenden und uns nicht um den Datentyp kümmern… Doctrine macht alles für uns:

private string $status; 

Verwendung von Asserts zur Validierung von Eingaben

Wenn wir nun eine Eingabe mit einem speziellen Datentyp validieren wollen, können wir diese Einschränkung mit Symfony/Validator verwenden. Dies ist nützlich für die Validierung von Formularen oder POST-Aufrufen.

status: 
  - NotBlank: ~ 
  - Choice: { callback: [ \[..]ProductStatusType, getValidValues] }  

Und Symfony prüft, ob der angegebene Wert in den zugelassenen Werten in unserem benutzerdefinierten Datentyp definiert ist…. Zauberei! ie Callback-Definition ruft die Methode getValidValues() auf und prüft, ob der angegebene Wert ein gültiger Wert ist.

Symfony ist großartig!

The post Arbeiten mit Enum-Typen in Symfony und PostgreSQL appeared first on WATA Factory.

Um in das Thema einzusteigen, müssen wir uns folgende Fragen stellen: (1) Was verstehen wir unter einem Legacy-Projekt? (2) Wenn es funktioniert, warum sollen wir es ändern? (3) Wie machen wir das? Schauen wir es uns an!

Was verstehen wir unter einem Legacy-Projekt?

Für uns ist ein Legacy–Code (oder Spaghetti-Code) ein Code, bei dem das, was wir für gute Entwicklungspraktiken (Clean Code) halten, weder angewendet wird, noch SOLID-Prinzipien folgt und darüber hinaus keine gute (oder überhaupt gar keine) Testabdeckung hat.

In der Regel handelt es sich bei diesem Code um einen alten Code, der seit mehreren Jahren in Verwendung ist (und mehr oder weniger verlässlich ist), der ohne Framework oder, in dessen Ermangelung, unter Verwendung einer alten Version eines solchen entwickelt wurde (z.B. Symfony 2).

Wenn es funktioniert, warum sollen wir es ändern?

Das ist eine sehr gute Frage, vor allem weil man in unserer Branche oft (manchmal zu oft) hört: was funktioniert, das ändert man nicht.

Die Antwort auf diese Frage ist nicht einfach. Wir sollten die Modernisierung (oder auch nicht) unter dem Aspekt der Nachhaltigkeit und der Stimmigkeit mit den Praktiken, die täglich im Unternehmen durchgeführt werden, in Betracht ziehen.

• Nachhaltigkeit, denn wenn wir von einem laufenden Projekt sprechen erreichen wir jedes Mal, wenn eine neue Entwicklung gemacht wird, nur, dass wir das Monster weiter füttern. Es wird die Zeit kommen in der diese Modernisierung, von der wir gesprochen haben, praktisch unmöglich sein wird, ohne viel Zeit und damit auch Geld zu investieren.

• Stimmigkeit, denn wenn die neuen Projekte einer Reihe von Qualitätsstandards, Einheits- oder Integrationstests usw. folgen, warum werden wir dann laufende Projekte haben, bei denen diese Praktiken nicht angewendet werden, nur weil es sich um ein langfristiges Projekt handelt?

Wie machen wir das?

Wenn wir an diesem Punkt angekommen sind, dann weil wir davon überzeugt sind, dass wir unseren Code erneuern wollen.

Bei WATA Factory arbeiten wir mit Symfony, also werden wir in unserem Fall ein Projekt zu diesem Framework erstellen und den Legacy–Code darin integrieren.

Wenn wir neue Funktionen erarbeiten, werden wir diese im Rahmen des Symfony-Projekts entwickeln. Die alten Funktionen werden in dem, was wir LegacyBundle nennen werden, enthalten sein. Wir setzen diesen Prozess um, indem wir die in diesem Leitfaden (veröffentlicht von Yannick de Lange) aufgeführten Schritte befolgen.

Dieses Bundle wird das gesamte Legacy-Projekt enthalten, und durch Routing werden wir unsere neuen Endpunkte auf den alten Code umleiten, so dass alles weiterhin funktioniert.

Diese Struktur gibt uns die Möglichkeit, nicht das gesamte Projekt auf einmal migrieren zu müssen, mit der damit verbundenen Zeit und dem Risiko, das dies mit sich bringt. Wenn wir bestehende Funktionalitäten modifizieren, müssen wir daran denken sie aus dem Legacy Bereich herauszunehmen und in den neuen Bereich einzufügen. Dies wird dazu führen, dass der Legacy-Teil im Laufe der Zeit immer kleiner wird.

Wenn aus irgendeinem Grund Symfony nicht verwendet wird und der Legacy–Code und der neue Code nicht nebeneinander existieren können, empfehlen wir dem Leitfaden zu folgen, der in dem Buch Modernizing Legacy Applications in PHP von Paul M. Jones enthalten ist.

Paul M. stellt uns Richtlinien zur Modernisierung des Projekts zur Verfügung, einschließlich Autoload, Refactoring des Codes usw.

The post Modernisierung von PHP-Legacy Projekten durch Symfony appeared first on WATA Factory.