-4

Web サイトで実行される一般的な操作を想像してみましょう。

ユーザーがボタンを押した後、アプリケーションは次のことを行う必要があります。

  1. 操作が許可されているかどうかの条件を確認します (ユーザー権限、オブジェクトの一貫性、関係など)。
  2. DB レコードの更新
  3. 報告

これはビジネス ロジック層の関心事であり、多くの本に書かれています。実際、最初にDBからデータを読み取り、次にDBにデータを書き込みます。また、チェック中に他のユーザー/プロセスによってデータが変更された場合、無効な結果がデータベースに入れられます。問題はよく知られているようですが、私はまだこれに対する良い解決策を見つけることができません.

問題は、ビジネス トランザクションを維持する機会がないのに、なぜビジネス ロジック層が必要なのかということです。

おそらく、TransactionScope と言うでしょう。では、読み取りデータが外部プロセスによって変更されないようにするにはどうすればよいでしょうか? ビジネス層から UPDLOCK を実行するにはどうすればよいですか? 可能であれば、ストアド プロシージャでトランザクションを実行するよりもはるかにコストがかかるのではないでしょうか?

ロジックの一部を DB に持ち込む方法はなく、全体のみです。パート 1 と 2 の両方を同じトランザクションで実装する必要があり、さらに、更新が行われるまで読み取りデータをロックする必要があります。

アイデア?

4

1 に答える 1

1

私は本当にあなたが間違った角度からこれを主張していると思います。まず、あなたの特定の例では、あるユーザーによる投票の変更が、別のユーザーが賛成票に影響を与えようとする試みを無効にするということは何もないようです。したがって、ページを開いてアイテムに 200 票があり、賛成票をクリックした場合、その間に他の 10 人が同じことをしたかどうかは気にしません。そのため、検証はビジネス層で実行でき、その結果、投票が通過できる場合は、単一の SQL ステートメントを使用してアトミックな方法で更新を行うことができます (例: UPDATE Votes SET VoteCount = VoteCount+1 WHERE ID= @ID)、または UPDLOCK を使用した選択とトランザクションでラップされた更新。ORM と開発者が後者のアプローチを採用する傾向は、あちらこちらでもありません。

ここで、投票数の更新が実際に私の投票を無効にすることが要件である場合、それはまったく別の状況です。この場合、楽観的または悲観的な同時実行を使用することは絶対に正しいですが、これらは (明らかに) 何百人もの人々が同じ項目に対して同時に投票する Web サイトには適用できません。ここでの問題は実装ではなく、複数の人が同じ項目で作業できるようにする性質です。

つまり、要約すると、DB の外部にビジネス層を持ち、インクリメントをアトミックに保つことを妨げるものは何もありません。同時に、DB の外部にビジネス ロジックを配置することのメリットも享受していただければ幸いです (これ自体は投稿ですが、大きなメリットだと思います)。

于 2012-04-12T11:50:13.590 に答える