(CJP) 一部の大規模な Laravel プロジェクトでは、リクエスト データをデータ転送オブジェクトにマッピングすることを好みます。 そうすることで、実際に扱っているデータの種類に関する静的分析の洞察を得ることができます。
このような request/dto セットアップは通常、次のようになります。 生の受信データの検証を処理するリクエスト クラスを次に示します。
class PostEditRequest extends Request
public function rules(): array
return [
‘title’ => [‘required’, ‘string’, ‘unique:posts,title’, ‘max:255’],
‘status’ => [‘required’, ‘string’],
‘body’ => [‘required’, ‘string’],
‘date’ => [‘required’, ‘date_format:Y-m-d’],
‘author_id’ => [‘nullable’, ‘exists:authors,id’],
‘tags’ => [new CollectionRule(Tag::class)],
];
PHP、IDE、および外部の静的アナライザーがデータを理解できるように、そのデータを表す DTO を次に示します (ここでは data-transfer-object パッケージを使用していることに注意してください)。
class PostEditData extends DataTransferObject
public string $title;
public PostStatus $status;
public string $body;
public Carbon $date;
public ?string $authorId;
public array $tags;
最後に、検証済みの要求データを DTO に変換し、それをアクション クラスに渡してビジネス プロセスで使用するコントローラーがあります。
class PostEditController
public function __invoke(
UpdatePostAction $updatePost,
Post $post,
PostEditRequest $request,
)
return $updatePost(
post: $post,
data: new PostEditData(…$request->validated()),
);
私は、この 2 段階の要求/dto 変換に関連するオーバーヘッドについて考えてきました。 最終的には、サーバーに送信されるデータの有効な型付き表現のみが重要であり、未加工のリクエスト データの配列の操作はあまり重要ではありません。
tpyoに気づきましたか？ PR を送信して修正することができます。 このブログの最新情報を知りたい場合は、私をフォローしてください。 ツイッター または私のニュースレターを購読してください：
それでは、なぜそれを正確に行わないのでしょうか? 手動で DTO に変換するオーバーヘッドなしに、リクエスト クラスを適切に型付けする方法を用意してください。
ここでサスペンスを構築して、皆さんを興奮させることもできますが、読者が情報に基づいた独自の結論を引き出すことができると信じているので、最終的にどのようになるかをお見せします。
class PostEditRequest extends Request
public string $title;
public PostStatus $status;
public string $body;
public Carbon $date;
public ?string $authorId;
public array $tags;
検証とデータ表現という 2 つの役割を 1 つのクラスにまとめていると言う人もいるかもしれません。 彼らは正しいですが、古いアプローチも何ら変わりはなかったと思います。 をもう一度見てください。 rules 古いリクエストのメソッド:
class PostEditRequest extends Request
public function rules(): array
return [
‘title’ => [‘required’, ‘string’, ‘unique:posts,title’, ‘max:255’],
‘status’ => [‘required’, ‘string’],
‘body’ => [‘required’, ‘string’],
‘date’ => [‘required’, ‘date_format:Y-m-d’],
‘author_id’ => [‘nullable’, ‘exists:authors,id’],
‘tags’ => [new CollectionRule(Tag::class)],
];
ここでは型情報も検証していますが、それは隠されているだけで、IDE や他の静的アナライザーでは解釈できません。 私が提案する唯一の変更点は、PHP の組み込み型システムを最大限に適切に使用し、より複雑な検証規則のギャップを属性で埋めることです。
最後に、コントローラーは次のようにリファクタリングできます。
class PostEditController
public function __invoke(
UpdatePostAction $updatePost,
Post $post,
PostEditRequest $data,
)
return $updatePost(
post: $post, data: new PostEditData(…$request->validated()), data: $data,
);
ちなみに、私がこのアイデアを思いついただけではありません。これを正確に実行する最新の Web フレームワークがいくつかあります。
最後に、これを Laravel で実装するのはそれほど難しいことではないと思います。 そのためのスタンドアロン パッケージを作成することもできます。 必要なのは、リクエストのパブリック プロパティに基づいてリクエスト ルールを動的に構築し、リクエストが来るたびにそれらを埋めることだけです。作業の最大の部分は、Laravel のすべての検証ルールをサポートする属性を作成することだと思います。
とにかく、人々がそれについてどう思うかを見るために、私はアイデアをそこに投げ出しています. あなたの考えを自由に共有してください ツイッター 私と一緒に。