1

Webアプリの楽観的同時実行シナリオでは、GUIDに相当するタイムスタンプ列（sqlserver）を各テーブルに与えることを検討しています。エンティティへのLinqはWHERE id = @p0 AND timestamp = @p1、Entity Frameworkの特定の属性でタイムスタンプ列を装飾する場合のように、SQL更新クエリを生成します。返される更新されたレコードの数がである場合、0同時実行例外が検出されました。

多くの投稿で、私は自己追跡エンティティについて読んでいます。これは、代替またはより良い解決策になる可能性があります。しかし、上記の「単純な」タイムスタンプ方式に勝る利点は見当たりませんでした。データベースが不変であり、タイムスタンプ列を提供しないシナリオは別として。

どのソリューションが優れているのか、そしてその理由は何ですか？

編集

Yury Tarabankoは、STEは別の概念であると正しく述べています。ただし、zeeshanhiraniの回答は、同時実行性チェックが変更を追跡する主な動機の1つであることを示しています。

質問を言い換えると、「タイムスタンプ列」メソッドが非常に簡単に見える場合に、なぜ誰もが同時実行チェックにSTEの概念を使用するのでしょうか。

4

2 に答える 2

1

ここでは2つの概念を混ぜ合わせています。STEは並行性についてはまったく関係ありません。

自己追跡エンティティは、それらの変更がどのように行われたかに関して、変更追跡を行う方法を知っているだけです。したがって、エンティティオブジェクトグラフの現在の状態を常に把握できます。また、追加の変更検出を呼び出す必要はありません。

STEとは何ですか。

編集：

「同時実行チェックは、変更を追跡する主な動機の1つです」

AFAIK STEとPOCOは、同時実行性チェックへの同じアプローチを共有します。これにより、更新ステートメントの追加のwhere条件がDBに送信されます。これに相当します：

UPDATE [schema].[table] 
     SET [prop1] = value1, ... 
     WHERE [key] = key_value 
          AND [concurrency_prop_1] = concurrency_prop1_old_value 
          AND [concurrency_prop_2] = concurrency_prop2_old_value

したがって、変更を追跡する「主な動機」は、N層アプリの変更を追跡することです。

于 2010-07-05T20:56:31.310 に答える
0

自己追跡エンティティは、実際には、説明した概念で機能します。STEは基本的に、コンテキストが存在しない場合のオブジェクトへの変更を追跡します。ただし、WCFサービスを使用して変更をサーバーに送信すると、プロパティの現在の値、エンティティの新しい状態、および主キー列の元の値、独立した関連付けの値、および任意の列の元の値が送信されます。エンティティデータモデルでConcurrency=Fixedとしてマークされているもの。

于 2010-07-07T05:34:40.123 に答える