なぜ隠しフィールドが使用されるのですか？
私はいつもWebアプリケーションで使用される多くの隠しフィールドを見てきました。私は、多くの非表示フィールドと、それらに送受信される表示フィールドのデータ値を使用するように記述されたコードを使用して作業しました。なぜ隠しフィールドが使われるのか理解できませんが。ほとんどの場合、隠しフィールドを使用せずに同じ問題を解決する方法を考えることができます。隠しフィールドは設計にどのように役立ちますか？
隠しフィールドが提供する利点は正確に何であるか誰かに教えてもらえますか？なぜ隠しフィールドが使用されるのですか？
隠しフィールドは最も簡単な方法です。そのため、隠しフィールドはかなり使用されます。
代替案：
- セッションサーバー側にデータを保存する（sessionid cookieを使用）
- トランザクションサーバー側にデータを保存する（トランザクションIDを単一の非表示フィールドとして）
- 該当する場合、非表示フィールドのクエリパラメータの代わりにURLパスを使用する
主な懸念事項：
- 非表示フィールドの値は、（サーバー側のストレージとは対照的に）ページ間で改ざんされないことを信頼できません。
- ビッグデータは毎回投稿する必要があり、問題になる可能性があり、一部のデータ（アップロードされた画像など）では不可能です。
主な利点：
- ページと複数のブラウザウィンドウの間にこぼれるスティッキーセッションはありません
- サーバー側のクリーンアップは必要ありません（期限切れのデータの場合）
- クライアント側のスクリプトにアクセス可能
オブジェクトを編集するとします。ここで、IDを非表示フィールドに配置すると便利です。もちろん、その値に依存しないでください（つまり、ユーザーがinsert/updateに対して適切な権限を持っていることを確認する必要があります）。
それでも、これは非常に便利なソリューションです。表示フィールド（読み取り専用テキストボックスなど）にIDを表示することは可能ですが、ユーザーを苛立たせます。
IDをセッション/ Cookieに保存することは、同時に開いている複数の編集ウィンドウを禁止し、有効期間の制限を課すため、禁止されています（セッションのタイムアウトにより、編集操作が中断され、非常に煩わしくなります）。
URLを使用することは可能ですが、デザインルールに違反します。つまり、データを変更するときにPOSTを使用します。また、ユーザーに表示されるため、醜いURLが作成されます。
私が見たり使用したりする最も一般的な用途は、サーバーに送り返すために必要な場合以外の理由で実際にページに表示する必要のないIDなどです。
-編集、詳細を含める必要があります-
たとえば、更新したいオブジェクトがあるとします。UIは値のコレクションを送り返し、その時点でサーバーは「これは顧客オブジェクトです」と認識している場合と認識していない場合があるため、サーバーにリクエストを送信し、 「ねえ、ID 7をください」と言うと、システムが認識している顧客オブジェクトが作成されます。更新が適用され、検証され、UIが完成した結果を取得します。
良い言い訳/議論はlinqを使用していると思います。最初にDBから取得せずに、linqのオブジェクトを更新してみてください。あなたが完全なオブジェクトを手に入れるまでそれが追跡できるものであるということは本当の考えを持っていません。
ここに1つの理由、クライアントコード（javascript）とサーバー側の間でデータを渡す便利な方法があります。
多くの有用なシナリオがあります。
1つは、ユーザーが入力してはならないページにデータを「保存」することです。たとえば、ページを生成するときにユーザーIDを保存すると、この値はフォームとともにサーバーに自動送信されます。
もう1つのシナリオはセキュリティです。ページに非表示のトークンを追加し、サーバー上に存在することを確認します。これは、フォームがブラウザ経由で送信されたのか、サイトのURLに投稿したばかりのボットによって送信されたのかを識別するのに役立ちます。
それは（クエリ文字列のように）URLから物事を遠ざけるので、それをきれいに保ちます。また、必ずしもそこにある必要がないかもしれないものをセッションから遠ざけます。
それ以外は、あまり多くのメリットは考えられません。
これらは通常、相互作用が進行するときに状態を保存するために使用されます。代わりにCookieを使用することもできますが、無効にする人もいます。単一の非表示フィールドを使用してサーバー側の状態を指すこともできますが、セッションのスティッキ性の問題があります。