ASP.NETサーバーデータの永続性

Question

質問がどのように表現されるべきか正確にはわかりませんので、間違ったことを尋ねると我慢してください。

言語の背後にあるコードとしてVBを使用してASP.NETアプリケーションを書いています。 DBに接続してクエリ（もちろんパラメーター化された）を実行するデータアクセスクラスと、検証タスクを実行する別のクラスがあります。ASPXページからこのクラスにアクセスします。

私が望むのは、データサーバー側を保存し、ユーザーがデータの有効性に基づいていくつかのオプションから選択するのを待つことです。しかし、私の理解が完全にオフになっていない限り、サーバー上に永続的なデータオブジェクトを持つことは、複数のユーザーが接続すると問題が発生しますか？

私の最終的な目標は、データが検証されると、エンドユーザーが変更できないことです。現在、私はデータを検証していますが、ユーザーがOKと言った後もWebフォームから取得する必要があります。しかし、私はチャンスをつかまないことを望んでいます）。

それで、私は完全に理解していますか？もしそうなら、誰かがサーバー上に永続的なデータを保持するための指示を提供するリソースを私に向けるか、指示を提供することができますか？

ありがとう！

---

具体的な例：

私たちは最近、検査官ガジェットを雇い、高速道路の標識を検査している標識検査官のデータを挿入して、通常は青少年市議会の傑出したメンバーであるバブル・ガム・チューインによって壊れたり盗まれたりしていないことを確認しました。

ガジェットが彼の気性を証明できれば、彼は実際の標識検査を行うように昇進するかもしれません。今のところ、彼の唯一の仕事は、このイントラネットサイトに最新の検査に関する入力情報を行くことで構成されています。地区、郡、ルート＃、道路のセクション、および日付のサインが設置され、検査されました。

もちろん、80年代後半に生きていた私たちは誰でもガジェットの無能さに精通しています。したがって、このサイトは、私たちができる限りガジェットの証明です。地区/郡/ルートはすべてドロップダウンリストを通じて記入されており、彼はセクションの開始と終了、および日付を手動で入力する必要があります。時々、彼はマウスを手探りし、セクションの開始と終了を交換します。そのため、テキストは赤くなり、間違いを彼に警告します。残念ながら、彼は今日、すべての赤い色を黒に変える反赤のサングラスを着用することを選びました。さて、データを送信しようとした後、彼がどこで何を修正する必要があるかを示すエラーメッセージが彼に表示されます。残念ながら、彼はキーボードを羽ばたき、1.337を入力する代わりに13.37（マイル）に入れました - 道路の長さはわずか10マイルです！さて、今、メッセージ（モーダルDIV）がポップアップし、道路の本当の走行距離は0-10であり、彼のエントリが道路の3つのセクションを組み合わせることを彼に伝えます。その後、彼は選択する3つのボタンが与えられます。キャンセル。これにより、13.37を10に変換するデータを制約して変更することができます。

「ヨウザ！」ガジェットは叫び、クリックしてキャンセルして戻って彼の間違いを修正しました。まあ、彼が正しく入力する次のデータセットであるため、確認メッセージが表示され、彼が行っていた変更を示し、継続することが問題であるかどうかを尋ねました。まあ、残念ながら、検査官のガジェットはコーヒーカップをノックし、机の上に残骸を散らしました。それをきれいにするために急いで、彼は「OK」をクリックしましたが、彼のゴーゴーグの電磁石が誤って彼のコンピューターでいくつかのビットをひっくり返し、アーカンソー州からAkrsanas、DOHに郡を変えました！

キャンパス全体のサーバーにデータが保存されていて、合格した情報は「OK」または「キャンセル」であった場合、これは避けられていたでしょう。

---

もちろん、私はいつでも検証できます また 「OK」の後、しかし、それはハッキーな回避策のように思えます。

とにかく、私はこれが明確になることを願っています！

Answer 1

WebServerのキャッシュを使用することを考えていると思います。 ASP.NETでは、Context.cacheを使用してサーバーにデータを保存できます。 1つのユーザーキャッシュが発生すると、サーバー上の他のユーザーもアクセスできます。

データはサーバー上にキャッシュされているため、DBの更新クエリを呼び出すたびにキャッシュをクリアしたいと思います。次に、データをロードするときに、データを再度キャッシュに保存できます。

選択方法では、キャッシュ[キー]がnullでないかどうかを確認します。その場合は、データを返す前に、DBからデータをロードしてからキャッシュ[キー]に保存します。 nullでない場合は、DBの代わりにキャッシュから単純にロードします。

使用するキーは、パラメーターを含めることができるため、キャッシュからデータをフィルタリングする必要はありません。次に、データでlinqクエリを実行してパラメーターをフィルタリングできます

これが役立つことを願っています。

Answer 2

私はあなたが言及していると思います 並行性. 。リンクをチェックして、それがあなたが尋ねていることである場合、それを理解することを始めてください。おそらく、バックエンドと特定の状況に応じて、もう少し調査する必要があります。繰り返しますが、これがあなたが探しているものであるなら、あなたは粒子に興味があるかもしれません 悲観的 並行性。

http://en.wikipedia.org/wiki/concurrency_control

---

編集： あなたの例を読んだ後....あなたは次のことをしたいかもしれないように聞こえます、幸運。

1. レコードを「ロック」します ある種の悲観的な並行性パターンを使用します （DBでは、データが実際にある場所です）ユーザーがデータを入力することによってアクセスされるとき。これは、DBレコードを読み取るようにするようなものです。

2. ユーザーがOKにヒットしたら、おそらくASP.NETコードを介して検証する必要があり、検証が渡された場合は、DBを更新してDBレコードのロックを解除する必要があります。

3. ユーザーがキャンセルした場合、DBレコードを更新しないでください。ロックを解除してください。

4. ユーザーが入力を強制したい場合は、DBを更新してDBレコードのロックを解除するだけです。