なぜビジネスロジックですか？

Question

Webサイトで一般的な操作が実行されているとしましょう。

1. チェック条件操作が
2. （ユーザー権利、いくつかのオブジェクトの一貫性、関係および他のもの）は許可されているかどうかを更新DBレコード
3. レポート：ユーザーがボタンを押すと、アプリケーションがすべき後

これは数多くの書籍で書かれているように、ビジネスロジック層の懸念事項です。 実際には、まずDBからデータを読み込み、DBにデータを書き込みます。また、チェック中に他のユーザー/プロセスによってデータが変更された場合、無効な結果がデータベースに格納されます。問題のようなものはよく知られているはずですが、私はまだこのための良い解決策を見つけることができません。

質問は次のとおりです。なぜ、保守業務トランザクションの機会のないビジネスロジック層が必要なのでしょうか？

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

ロジックの一部をDBに持ち込む方法はありません。両方の部品＃1と＃2が同じトランザクションで実装されなければならず、さらに、更新が完了するまで読み取りデータをロックする必要があります。

アイデア？

Answer 1

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

投票数の更新が実際に自分の投票を無効にするという要件であれば、まったく別の状況です。この場合、私たちは楽観的または悲観的同時実行性を使用するのは間違いありませんが、同じアイテムに対して何百人もの人々が同時に投票できるWebサイトには当てはまりません（明らかに）。ここでの問題は実装ではなく、複数の人が同じアイテムで作業できるようにするという性質です。

要約すると、DBの外にビジネスレイヤーを持ち、増分をアトミックに保つことを止めるものは何もありません。同時に、ビジネスロジックをDBの外に持つ利点を楽しむこともできます（それ自体がポストですが、大きな利点だと主張しています）。