Ceci est mon premier article, alors préparez-vous à attraper les pierres.
Lors de l'écriture d'une nouvelle méthode ou d'un nouveau service, nous essayons de l'abstraire autant que possible des dépendances externes afin que la nouvelle fonctionnalité n'implémente que la logique prévue pour elle. En fait, c'est ce que nous dit l'un des principes SOLID - le principe de responsabilité unique .
Je tombe constamment sur un code où si une méthode a plus de deux arguments d'entrée, un conditionnel (tableau $ args) est ajouté, ce qui implique la mise en œuvre d'un contrôle de la présence d'une clé, ou elle est absente, puis la probabilité que la méthode peut être repeinte lors des augmentations d'exécution.
Peut-être qu'une telle approche en PHP s'est développée historiquement, en raison du manque de typage fort et d'une telle POO. Après tout, comme pour moi, seulement à partir de la version 7, il était possible d'implémenter plus ou moins le typage + POO, en utilisant strict_types et le type hinting.
Aussi, l'appel de telles méthodes peut être accompagné d'une description du tableau que nous passerons. Ou une sorte de tableau avec des déchets est passé du tout, et la méthode prend simplement les clés dont elle a besoin. Par exemple, un service de création d'un utilisateur:
$userService->create([
'name' => $object->name,
'phone' => $object->phone,
'email' => $object->email,
]);
, DTO’. DTO , , . . , , , .
DTO, , . . , , , , .
ClassTransformer
. . , . Laravel :
class UserController extends Controller {
public function __construct(
private UserService $userService,
) {}
public function createUser(CreateUserRequest $request)
{
$dto = ClassTransformer::transform(CreateUserDTO::class, $request);
$user = $this->userService->create($dto);
return response(UserResources::make($user));
}
}
class CreateUserDTO
{
public string $name;
public string $email;
public string $phone;
}
: name, phone email. , , , . . transform , object, .
. , DTO, :
class CreateUserDTO
{
public string $name;
public string $email;
public string $phone;
public static function transform(mixed $args):CreateUserDTO
{
$dto = new self();
$dto->name = $args['fullName'];
$dto->email = $args['mail'];
$dto->phone = $args['phone'];
return $dto;
}
}
, , . ? , PHPDoc . , :
class PurchaseDTO
{
/** @var array<\DTO\ProductDTO> $products Product list */
public array $products;
/** @var \DTO\UserDTO $user */
public UserDTO $user;
}
, . .
, .. . alias , .
?
,
,
IDE .
, . Spatie - https://github.com/spatie/data-transfer-object
DTO, DTO, , . , new DTO() .
, , NestJS - plainToClass. , , . ORM ( ), :)
Roadmap
Implémentez la méthode afterTransform qui sera appelée après l'initialisation du DTO. Cela vous permettra de personnaliser de manière plus flexible le casting à la classe. Pour le moment, si les clés d'entrée sont différentes des DTO internes, vous devez décrire vous-même la méthode de transformation. Et si sur 20 paramètres, un seul a une clé différente, nous devrons décrire la conversion de tous les 20. Et avec la méthode afterTransform, nous pouvons personnaliser la conversion du seul paramètre dont nous avons besoin, et tout le reste sera traité par le paquet.
Prise en charge des attributs PHP 8
C'est tout.