Ktouth Brand. on Web

昨日の日記で書いたとおり、以前アップした追加処理ではリレーションシップの両端が新規オブジェクトの場合に、それが正しく反映できないという問題がありました。
今回、その対応を含めた処理の修正コードを提示します。

(以下、修正した実装コード)

修正の概要

今回の修正は、エンティティ型およびコンテキスト型のイベントハンドラ、両方に及びます。
要するに「リレーションシップの両端が常に一意的である」ならOKな訳ですから、独自の追加処理(＝Idの設定)を全ての追加エンティティに行った後にコンテキストへの再接続処理を行うようにすれば問題ありません。
具体的には以前アップした追加処理の最後の方の処理概要の4〜7番を、4とそれ以降の2段階に分けて行えばいいわけです。以前のコードでは一つのループでやっていました。

また、リレーションシップの変更はxxxxReferenceというプロパティを参照することで変更イベントをフックすることが出来ますが、これは通常の変更時でもAttach時にも発生するした上にその区別が付きません。
状況によってはこの区別が付いた方が良いと思われるので、そのための処理も追加します。

修正：エンティティ型に追加処理を実装する

interface IEntityInsertHelper
{
　　bool InProcessing { get; set; }
　　void InsertItem(SqlCeConnection connection);
}

追加したプロパティは後に使用する再アタッチ処理の判別用プロパティです。

#region IEntityInsertHelper メンバ

bool IEntityInsertHelper.InProcessing { get; set; }

void IEntityInsertHelper.InsertItem(SqlCeConnection connection)
{
　　if (Id != 0) { return; }

　　// TODO: 必要なら、ここに必須エンティティの追加処理を呼び出す

　　var command = connection.CreateCommand();
　　command.CommandText = "INSERT INTO AddressGroup(AreaId, Name, Deleted, Apartments, Format, InputFormat, OldId, Created)" +
　　　　　　　　　　　　　 "　VALUES (@area, @name, @deleted, @ap, @format, @input, @old, @created)";

　　command.Parameters.Add(new SqlCeParameter("area", this.Area.Id));
　　command.Parameters.Add(new SqlCeParameter("name", this.Name));
　　command.Parameters.Add(new SqlCeParameter("deleted", this.Deleted));
　　command.Parameters.Add(new SqlCeParameter("ap", this.Apartments));
　　command.Parameters.Add(FooEntities.CreateNullOrValue("format", this.Format));
　　command.Parameters.Add(FooEntities.CreateNullOrValue("input", this.InputFormat));
　　command.Parameters.Add(FooEntities.CreateNullOrValue("old", this.NewestInfo, x => x.Id));
　　command.Parameters.Add(new SqlCeParameter("created", this.Created.Date));

　　command.ExecuteNonQuery();

　　this.Id = FooEntities.GetKey(connection, this);
}

#endregion

コンストラクタ()
　　: base()
{
　　(this as IEntityInsertHelper).InProcessing = false;
}

エンティティ型での追加コードは先ほどの InProcessing プロパティの実装と初期化です。プロパティの実装を省略表記で記述しているため、初期化処理をコンストラクタで行っています。
また InsertItem メソッドの最初で再入判定処理を行っています。複数回呼び出しても大丈夫なようにキーの値が設定されているかを見て判断しています。

修正：イベントハンドラで追加処理を差し替える

FooEntities() {
　　this.SavingChanges += ContextSavingChanges;
}

private void ContextSavingChanges(object sender, EventArgs e)
{
　　// TODO: ここで適切な追加・変更オブジェクトの検証処理を行う

　　SqlTransaction((c, t) =>
　　{
　　　　var stack = new List<IEntityInsertHelper>(
　　　　　　from ent in _Context.ObjectStateManager.GetObjectStateEntries(EntityState.Added)
　　　　　　where ent.Entity is IEntityInsertHelper
　　　　　　select ent.Entity as IEntityInsertHelper
　　　　);
　　　　foreach (var obj in stack) { obj.InsertItem(c); }
　　　　foreach (var obj in stack)
　　　　{
　　　　　　try
　　　　　　{
　　　　　　　　obj.InProcessing = true;
　　　　　　　　_Context.Detach(obj);
　　　　　　　　(obj as EntityObject).EntityKey = _Context.CreateEntityKey(typeof(XxxEntities).Name + "." + obj.GetType().Name, obj);
　　　　　　　　_Context.Attach(obj as IEntityWithKey);
　　　　　　}
　　　　　　finally { obj.InProcessing = false; }
　　　　}
　　});
}

イベントハンドラ、特にトランザクション処理の内部はほぼ総書き換えになっています。
一端 stack リストに追加対象オブジェクトをコピーしているのは、ObjectStateManager.GetObjectStateEntries の返値はオブジェクトの再アタッチをするたびにリストから無くなってしまうため、今回のようにループを複数回行うためには一端どこかに保持しておく必要があったからです。また、修正前のようにいちいち if 文を使って判定するのではなく、LINQ 文を使って見やすいコードに替えてみました。
再アタッチ処理に関しては対象オブジェクトに処理の最中であることを通知するために、新設した InProcessing プロパティを使っています。

追加の順番は不定なのか？

ここで気になるのが、一対多のリレーションシップで繋がっている時に追加の順番が適切に並んでいるか、です。
上記の InsertItem メソッド例のコードで言えば、this.Area が新規オブジェクトの際に、this.Area.Id が適切な(0以外の)値になっているかという問題です。
デバッグ時のトレース情報を見る限りは、単純なリレーションシップの場合に ObjectStateManager.GetObjectStateEntries で得られる列挙値の並びは、このリレーションシップを考慮したものになっているようです。
複雑な連携だったり、しっかりとした保証をかけたい場合は connection.CreateCommand() の処理の前あたりで、キーを確定したいエンティティの InsertItem メソッドを先に読んでおくといいと思います。先ほど追加した再入時の適切なスルー処理はそのためのものです。

とりあえず、これでリレーションシップを考慮した追加処理になったと思います。