私の以前の質問では、ほとんどのコメント提供者は、クライアント側とサーバー側の両方に検証ロジックがあることは良いことであることに同意しました。
ただし、問題があります。データベースとクライアントコード間で検証ルールの同期を維持する必要があります。
だから問題は、どうやってそれに対処できるかということです。
1つのアプローチは、ORM手法を使用することです。最新のORMツールは、サーバーに送信する前にデータ検証を処理できるコードを生成できます。
ご意見をお聞かせください。
この問題に対処するための標準的なプロセスはありますか？それとも、これはまったく問題ではないと思いますか？:)
編集：
皆さん、まずはご回答ありがとうございます。
明日はあなたの答えをまとめて、この場合のように質問のテキストを更新します
他の投稿への回答の 1 つで述べたように、レイヤーを分離したままにする場合、各レイヤーで検証ロジックが重複しないようにする良い方法はありません。それらを自動的に結び付けるために何かを使用すると、レイヤー間に一種の結合が導入され、将来の妨げになる可能性があります. これは、物事を手動で追跡する必要がある場合の 1 つかもしれません。
どのように進めても、各レイヤーが独自の検証を行っていることを確認する必要があります。そのレイヤーがどのようにアクセスされるかがわからないためです。実装したすべてのレイヤーが常に一緒であるという保証はありません。
検証するデータの出所を必ずしも気にしない検証サービスを使用するのが好きです。これは、検証ルールをクライアント (つまり Web ページ) に送信する部分に到達すると、いくつかの異なる方法で機能しますが、これの最も重要な側面は、実際の検証ルールに対して単一の権限を持つことだと思います。
たとえば、Validate メソッドを介してチェックされる ValidationRule オブジェクトのコレクションなど、データ コア エンティティに検証ロジックがある場合 (非常に典型的なシナリオ)、変換を介してそれらの同じルールをクライアント (javascript) に昇格させます。
ASP.NET の世界 (私が話すことができる唯一の世界) では、これを行う方法がいくつかあります。私が好む方法は、エンティティのフィールド (およびすべての検証ルール) に UI ウィジェットを結び付けるカスタム バリデータを作成することです。これの利点は、すべての検証ロジックを単一のバリデーターにバンドルできることです。欠点は、検証ルールがすべて一度にテストされるため、検証メッセージが密になることです。もちろん、これは、検証ロジックが最初の失敗などの言及のみを返すようにすることで軽減できます。
この答えは、漠然としていて不明確に聞こえるかもしれませんが、私が言いたい 2 つのポイントは次のとおりです。
一部のフレームワークは、クライアントとサーバーの検証を同期させる検証サポートを提供します。注釈を使用したこのSeam 検証チュートリアルをご覧ください。これは優れた実装であり、非常に理解しやすいものです。
とにかく、フレームワークに頼りたくないのであれば、似たようなものを実装するのは簡単だと思います。
ASP.Net を使用している場合は、使用できる検証コントロールが多数あります。これらのコントロールは非常に一般的な方法で記述されているため、コントロールのオプションを 1 か所で設定するだけであっても、ほとんどのコントロールはクライアントとサーバーの間で検証ロジックを自動的に複製します。
それらを自由に継承して、追加のドメイン固有のバリデータを作成することもできます。Web には、基本コントロールに追加するサードパーティ コントロール パックがあります。
ASP.Net を使用していない場合でも、これがどのように行われるかを調べる価値があります。独自のプラットフォームで同様のことを行う方法についてのアイデアを提供します。