【ITニュース解説】ASP .NET Core FluentValidation

データ検証とは、アプリケーションに入力されるデータが正しい形式であるか、必要な情報がすべて含まれているかなどをチェックする非常に重要なプロセスだ。例えば、ユーザー登録フォームでメールアドレスの形式が正しいか、パスワードが指定された文字数以上か、といった確認を行う。この検証がなければ、不正なデータがシステムに保存されたり、予期せぬエラーが発生したりする可能性があり、アプリケーションの信頼性やセキュリティが大きく損なわれる。

C#を使ったプロジェクトでは、このデータ検証を効率的に行うための便利なツールが「FluentValidation」だ。これは「NuGetパッケージ」と呼ばれる、開発でよく使われる機能やライブラリをまとめたもので、プロジェクトに簡単に追加して利用できる。特に、ウェブアプリケーションを開発するためのフレームワークであるASP.NET Coreで広く利用されてきた。

しかし、今回解説するニュース記事は、このFluentValidationに関して、これまでASP.NET Coreで使われていた特定のNuGetパッケージ「FluentValidation.AspNetCore」が非推奨（deprecated）になったという重要な変更についてだ。非推奨とは、今後新しい機能が追加されず、いずれはサポートが終了する可能性があることを意味する。そのため、現在このパッケージを使っているプロジェクトは、新しいバージョンのパッケージへと移行する必要がある。

この移行作業は、システムエンジニアを目指す上で避けて通れない、既存のシステムを最新の状態に保つための一般的な作業の一つだ。具体的なシナリオとしては、すでに「FluentValidation.AspNetCore」を使っているASP.NET Coreのプロジェクトがあり、それを新しいパッケージ構成へと変更する、というものになる。

移行を始める前の「準備」は非常に大切だ。まず、現在のプロジェクトのコードがきちんとコンパイルされ、意図した通りに動くことを確認する必要がある。そして、万が一移行作業で問題が発生した場合に元の状態に戻せるよう、現在のコードを「リモートリポジトリ」と呼ばれる共有のコード管理場所に「コミット」しておくことが強く推奨される。これは、Gitのようなバージョン管理システムで行う操作で、コードの変更履歴を記録し、いつでも過去の状態に戻せるようにしておくことだ。さらに、移行作業中は、完全に動作確認ができるまで途中でコミットしない、という鉄則も覚えておくと良い。これにより、中途半端な変更がリポジトリに記録されることを防ぐ。

実際の「移行ステップ」は、プロジェクトの構成ファイルである「.csproj」ファイルを編集することから始まる。Visual Studioのような開発環境のソリューションエクスプローラーから、該当するプロジェクトファイルを開く。そして、これまで使っていた「FluentValidation.AspNetCore」に関する記述を削除する。具体的には、<ItemGroup>タグの中にある<PackageReference Include="FluentValidation.AspNetCore" Version="11.3.1" />のような行を探して消去する。

代わりに、以下の新しいパッケージを参照する記述を追加する。 <ItemGroup>タグの中に、FluentValidation（データ検証の本体）、FluentValidation.DependencyInjectionExtensions（ASP.NET CoreでDIコンテナと連携するための拡張機能）、そしてMicrosoft.AspNetCore.Mvc.Abstractions（ASP.NET Coreのモデルの状態などを扱うための抽象化パッケージ）の3つを追加する。これらのパッケージは、それぞれ役割が異なるため、分離して提供されるようになった。これにより、必要な機能だけをプロジェクトに取り込むことができるようになる。

パッケージの参照を更新した後、プロジェクトを「ビルド」してみると、おそらく多くの「エラー」が発生するだろう。これは想定内のことだ。焦らず、一つずつエラーを解決していくことが重要になる。まずは、usingステートメント、つまりどの名前空間の機能を使うかを指定する行に関するエラーから修正するのが一般的だ。パッケージが変更されたことで、これまで使っていた機能が別の名前空間に移動したり、あるいはまったく新しい機能に置き換わったりしている可能性があるため、これらの記述を適切なものに更新する必要がある。

また、以前の「FluentValidation.AspNetCore」パッケージに特有の機能が、新しいパッケージには存在しない場合がある。例えば、検証エラーが最初に発生した時点で検証を停止する「CascadeMode.StopOnFirstFailure」という設定は、新しいパッケージでは「CascadeMode.Stop」という名前に変更されている。このようなAPIの変更に対応して、コードを修正していく必要がある。

さらに、記事では「AddToModelState」のような、以前は提供されていたが新しいパッケージには存在しない「拡張メソッド」への対応が示されている。拡張メソッドとは、既存のクラスに新しいメソッドを追加する機能のことだ。このような場合、記事に示されているように、自分で同じ機能を持つメソッドを実装する必要がある。この「AddToModelState」メソッドは、FluentValidationの検証結果（ValidationResult）を、ASP.NET Coreの「ModelState」にエラーとして追加するためのものだ。ModelStateは、フォームからの入力データが正しいか、検証エラーがないかを管理するための仕組みだ。自作のAddToModelStateメソッドは、検証結果が無効だった場合に、各エラーメッセージとプロパティ名を抽出して、ModelStateにエラーとして追加する処理を行う。

このように、ビルドエラーを一つずつ修正し、すべてのコードが正しくコンパイルされる状態、つまり「クリーンビルド」が達成できるまで作業を続ける。クリーンビルドができたら、それで終わりではない。最も重要なのは、アプリケーションの「テスト」だ。すべての機能が意図した通りに動作するか、データ検証が正しく行われているかを入念に確認する必要がある。特に、検証ロジックが変更された部分や、エラー表示に関する部分を中心にテストを行う。

すべての機能が問題なく動作することを確認できたら、最後にすべての変更内容をリモートリポジトリに「コミット」する。これで、今回のパッケージ移行作業は完了だ。

この一連の作業は、一見すると複雑に感じるかもしれないが、ソフトウェア開発の世界では日常的に発生する。技術は常に進化し、より良い方法が生まれていくため、それに合わせて既存のシステムも更新していく必要がある。非推奨になったパッケージからの移行は、システムの健全性を保ち、将来的な開発をスムーズに進めるために非常に重要なステップなのだ。この記事で示された基本的な手順と、エラー修正の考え方は、今後システムエンジニアとして様々な技術に触れていく上で役立つはずだ。