LINQ to SQL オブジェクトは常に何らかの状態に参加 します。 たとえば、LINQ to SQL が新しいオブジェクトを作成すると、オブジェクトは Unchanged 状態になります。 自分で作成した新しいオブジェクトは、 DataContext に対して不明であり、 Untracked 状態です。
SubmitChangesが正常に実行された後、LINQ to SQL と呼ばれるすべてのオブジェクトはUnchanged状態になります。 (単一の例外は、データベースから正常に削除された例外によって表されます。この例外は、 Deleted 状態であり、その DataContext インスタンスでは使用できません)。
オブジェクトの状態
次の表に、LINQ to SQL オブジェクトで使用できる状態を示します。
| 状態 | 説明 |
|---|---|
Untracked |
LINQ to SQL によって追跡されないオブジェクト。 次のような例があります: - 現在の DataContext (新しく作成されたオブジェクトなど) を介してクエリされないオブジェクト。 - 逆シリアル化によって作成されたオブジェクト - 別の DataContextを介して照会されたオブジェクト。 |
Unchanged |
現在の DataContext を使用して取得され、作成後に変更されたことが不明なオブジェクト。 |
PossiblyModified |
にDataContextオブジェクト。 詳細については、「 N 層アプリケーションでのデータ取得と CUD 操作 (LINQ to SQL)」を参照してください。 |
ToBeInserted |
現在の DataContextを使用して取得されないオブジェクト。 この場合、INSERT 中にデータベースの SubmitChanges が発生します。 |
ToBeUpdated |
取得後に変更されたことがわかっているオブジェクト。 この場合、UPDATE 中にデータベースの SubmitChanges が発生します。 |
ToBeDeleted |
削除対象としてマークされたオブジェクトがDELETE中にデータベースSubmitChangesを引き起こす。 |
Deleted |
データベース内で削除されたオブジェクト。 この状態は最終的な状態であり、追加の遷移を許可しません。 |
オブジェクトの挿入
Insertsを使用して、InsertOnSubmitを明示的に要求できます。 または、LINQ to SQL は、更新する必要がある既知のオブジェクトのいずれかに接続されているオブジェクトを見つけることで、 Inserts を推論できます。 たとえば、Untracked オブジェクトをEntitySet<TEntity>に追加したり、EntityRef<TEntity> オブジェクトにUntrackedを設定したりすると、グラフ内の追跡対象オブジェクトを使用してUntracked オブジェクトに到達できるようになります。
SubmitChangesの処理中に、LINQ to SQL は追跡対象オブジェクトを走査し、追跡されていない到達可能な永続的オブジェクトを検出します。 このようなオブジェクトは、データベースへの挿入の候補です。
継承階層内のクラスの場合、 InsertOnSubmit(o) は、 識別子 として指定されたメンバーの値を、 oオブジェクトの型と一致するように設定します。 既定の識別子の値と一致する型の場合、このアクションにより、識別子の値が既定値で上書きされます。 詳細については、「 継承のサポート」を参照してください。
Von Bedeutung
Tableに追加されたオブジェクトが ID キャッシュにありません。 ID キャッシュには、データベースから取得されたもののみが反映されます。
InsertOnSubmitの呼び出し後、SubmitChangesが正常に完了するまで、追加されたエンティティはデータベースに対するクエリに表示されません。
オブジェクトの削除
追跡対象オブジェクトoを削除対象としてマークする場合は、適切なDeleteOnSubmitで Table<TEntity>(o) を呼び出します。 LINQ to SQL では、 EntitySet<TEntity> からのオブジェクトの削除が更新操作と見なされ、対応する外部キー値が null に設定されます。 操作 (o) のターゲットは、そのテーブルから削除されません。 たとえば、cust.Orders.DeleteOnSubmit(ord)は、外部キーのcustを null に設定することで、ordとord.CustomerIDの関係が切断される更新を示します。
ordに対応する行は削除されません。
LINQ to SQL では、オブジェクトがテーブルから削除 (DeleteOnSubmit) されると、次の処理が実行されます。
SubmitChangesが呼び出されると、そのオブジェクトに対して
DELETE操作が実行されます。削除は、読み込まれているかどうかに関係なく、関連オブジェクトには反映されません。 具体的には、リレーションシップ プロパティを更新するための関連オブジェクトは読み込まれません。
SubmitChangesが正常に実行されると、オブジェクトは
Deleted状態に設定されます。 その結果、そのidでオブジェクトまたはそのDataContextを使用することはできません。 DataContext インスタンスによって保持される内部キャッシュでは、データベース内のオブジェクトが削除された後でも、新しいオブジェクトとして取得または追加されたオブジェクトは削除されません。
DeleteOnSubmitは、DataContextによって追跡されるオブジェクトでのみ呼び出すことができます。
Untracked オブジェクトの場合は、Attachを呼び出す前にDeleteOnSubmitを呼び出す必要があります。
DeleteOnSubmit オブジェクトで Untracked を呼び出すと、例外がスローされます。
注
テーブルからオブジェクトを削除すると、時に対応する SQL コマンドを生成するように LINQ to SQL に指示されます。 この操作では、キャッシュからオブジェクトが削除されたり、削除が関連オブジェクトに反映されたりすることはありません。
削除されたオブジェクトの id を再利用するには、新しい DataContext インスタンスを使用します。 関連オブジェクトをクリーンアップするには、データベースの 連鎖削除 機能を使用するか、関連オブジェクトを手動で削除します。
関連オブジェクトは、(データベースとは異なり) 特別な順序で削除する必要はありません。
オブジェクトの更新
変更の通知を監視することで、 Updates を検出できます。 通知は、プロパティ セッターの PropertyChanging イベントを通じて提供されます。 LINQ to SQL は、オブジェクトに対する最初の変更が通知されると、オブジェクトのコピーを作成し、そのオブジェクトを Update ステートメントを生成する候補と見なします。
INotifyPropertyChangingを実装していないオブジェクトの場合、LINQ to SQL では、オブジェクトが最初に具体化されたときに持っていた値のコピーが保持されます。 SubmitChangesを呼び出すと、LINQ to SQL は現在の値と元の値を比較して、オブジェクトが変更されたかどうかを判断します。
リレーションシップを更新する場合、子から親への参照 (つまり、外部キーに対応する参照) が権限と見なされます。 逆方向の参照 (つまり、親から子へ) は省略可能です。 リレーションシップ クラス (EntitySet<TEntity> と EntityRef<TEntity>) は、双方向参照が一対多リレーションシップと一対一リレーションシップに対して一貫性があることを保証します。 オブジェクト モデルが EntitySet<TEntity> または EntityRef<TEntity>を使用せず、逆参照が存在する場合は、リレーションシップの更新時に前方参照と一貫性を保つ必要があります。
必要な参照と対応する外部キーの両方を更新する場合は、それらが同意していることを確認する必要があります。 InvalidOperationException を呼び出したときに 2 つが同期しない場合は、SubmitChanges 例外がスローされます。 基になる行の更新に影響を与えるには外部キー値の変更で十分ですが、オブジェクト グラフの接続性とリレーションシップの双方向整合性を維持するように参照を変更する必要があります。