Este procedimiento está pensado para versiones de PHP anteriores a PHP 8.1 que incluyen el tipo nativo Enum. Podríamos aplicar la misma solución usando enums con unos pocos cambios o usando uno de los otros enfoques existentes. De todas formas, muchos proyectos siguen utilizando PHP 8.0 o anterior y este código sigue siendo útil para personalizar nuestros tipos enum en PostgreSQL con Doctrine y Symfony.

Imagina que has definido un tipo appointment_status como Enum en tu antiguo esquema de base de datos de la siguiente manera.

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

And you use this type in a certain column:

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)
  }

En este artículo aprenderemos a manejar este tipo de datos de forma sencilla.

Creación de un tipo Enum abstracto

El primer paso es crear una clase abstracta para este tipo de datos. Con esta abstracción, podemos reutilizar la clase para cualquier campo enum.

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; 
  }  
 
}  
 

Creación del tipo Enum

Ahora debes seguir la creación del Tipo Enum específico extendiendo la Clase Abstracta:

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

Consejo: Si la lista es demasiado larga, puede dividir la clase en dos archivos; la lógica por un lado, y los valores por otro, y obtener clases más mantenibles

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;
  }
}

Definir como tipo en Doctrina

En este punto tenemos que decirle a Symfony que tenemos un nuevo tipo de datos. Así, lo único pendiente es mapearlo en doctrine y hay que decirle «¡Eh, este tipo de datos es especial!». Edite el doctrine.yml y añada estas líneas:

doctrine: 
 dbal: 

 […] 
 mapping_types: 
 appointment_status: appointment_status 

 

 types: 
 appointment_status: App\..\AppointmentStatusType 

 

Mapeo de entidad con tipo de datos personalizado

¡Sí! Doctrine conoce ahora los únicos valores admitidos para el estado. En nuestro archivo XML de mapeo de entidades, ahora podemos utilizar:

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

En nuestro archivo de entidad, debemos utilizar «string» y no preocuparnos por el tipo de datos… Doctrine lo hace todo por nosotros:

private string $status; 

Uso de assets para validar entradas

Si ahora queremos validar un input con un tipo de dato especial, como vimos antes, podemos usar esta restricción usando Symfony/Validator. Esto es útil para validar formularios o llamadas POST.

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

Y Symfony comprobará si el valor dado está definido en los valores admitidos en nuestro tipo de datos personalizado…. ¡Magia! La definición de callback hace una llamada al método getValidValues() y comprueba si el valor dado es válido.

¡Symfony es genial!

The post Trabajando con Enum Types en Symfony y PostgreSQL appeared first on WATA Factory.

Para entrar en materia debemos plantearnos las siguientes preguntas: (1) ¿Qué entendemos como proyecto Legacy? (2) Si funciona, ¿para qué tocarlo? (3) ¿Cómo podemos hacerlo? ¡Veamos!

¿Qué entendemos como proyecto Legacy?

Para nosotros, un código Legacy (o código espagueti), es aquél donde no se aplica lo que consideramos buenas prácticas de desarrollo (Clean Code), no sigue los principios SOLID y no cuenta con una buena cobertura de tests (o directamente, ni siquiera los tiene).

Normalmente este código es un código antiguo con varios años en producción (y más o menos fiabilidad), desarrollado sin framework, o en su defecto, utilizando alguna versión antigua de alguno (por ejemplo, Symfony 2).

Si funciona, ¿para qué tocarlo?

Ésta es una muy buena pregunta, sobre todo porque en nuestro gremio se escucha mucho la expresión (a veces, demasiado) Lo que funciona, no se toca.

La respuesta a esta pregunta no es sencilla. Deberíamos plantearnos la modernización (o no) según sostenibilidad y coherencia con las prácticas que se realizan a diario en la compañía.

• Sostenibilidad porque si estamos hablando de un proyecto vivo, cada vez que se hace un evolutivo nuevo, lo único que conseguimos es seguir alimentando al monstruo. Llegará un momento en el que esa modernización de la que hablamos sea prácticamente imposible sin invertir una gran cantidad de tiempo, y por lo tanto, también de dinero.

• Coherencia porque si los nuevos proyectos siguen una serie de estándares de calidad, se realizan tests unitarios o de integración, etc., ¿por qué vamos a tener proyectos vivos, donde no se apliquen estas prácticas por el mero hecho de ser un proyecto ya de largo recorrido?

¿Cómo lo hacemos?

Si hemos llegado a este punto es porque estamos convencidos de querer renovar nuestro código.

En WATA Factory trabajamos con Symfony, así que en nuestro caso, crearemos un proyecto sobre dicho framework e integraremos el código Legacy en él.

Conforme vayamos realizando nuevas funcionalidades, las iremos desarrollando dentro del proyecto Symfony. Las antiguas funcionalidades estarán dentro de lo que llamaremos LegacyBundle. Llevamos a cabo este proceso siguiendo los pasos mostrados en esta guía publicada por Yannick de Lange.

Este Bundle contendrá todo el proyecto Legacy, y mediante el routing iremos redirigiendo nuestros nuevos endpoints al código antiguo para que todo continúe funcionando.

Esta estructura nos da la opción de no tener que migrar todo el proyecto de una vez, con el tiempo y riesgo que ello conlleva. Debemos tener en cuenta a la hora de modificar funcionalidades existentes, sacarlas de la parte Legacy e introducirlas en la nueva. Esto provocará que, con el paso del tiempo, la parte Legacy se vaya haciendo cada vez más pequeña.

Si por alguna circunstancia no utilizamos Symfony, y no pueden convivir juntos el código Legacy y el código nuevo, recomendamos seguir la guía que se nos proporciona en el libro Modernizing Legacy Applications in PHP, de Paul M. Jones.

Paul M. nos proporciona pautas para ir modernizando el proyecto, incluyendo autoload, refactorizando el código, etc.

The post Modernización de proyectos legacy en PHP a través de Symfony appeared first on WATA Factory.