FlagsAttributeでEntityState列挙が定義されている理由

Question

私は、アプリケーションに対して簡単なエンティティ変更ロギングを行っています。 DbEntityEntry.Stateプロパティの列挙値は明らかに相互排他的ですが（See MSDN）、それはFlags属性で定義され、値は組み合わせ可能な値として選択されます。

値が相互に排他的であると考えるのは安全ですか？なぜ彼らはこの道を選んだのですか？

Answer 1

値が相互排他的であると考えるのは安全でしょうか？

将来の互換性を計画している場合は、いいえ。著者は、現在の値の1つと組み合わせてより広い状態をカバーする値を追加することができる。あなたはマスキングの方が良いです。

これらはそうではないかもしれませんが、このように定義されていると、そのオプションは開いたままになります。

なぜこのパスが選択されましたか？

多分、値が相互に排他的であるとは思わないでしょう。

大抵、それは1つが、単一の試験で複数の値を覆うマスク・テストを実行することを可能にする。enumの値は、各セットの異なるビットを有するフラグレイアウトスタイルを使用するため

if (state & (EntityState.Deleted | EntityState.Modified | EntityState.Added) != 0) … 

これは動作（あるいは故意に別の用語で定義されている）：このため

Detached = 1, 
Unchanged = 2, 
Added = 4, 
Deleted = 8, 
Modified = 16 

、EntityState.Deleted | EntityState.Modified | EntityState.Addedは28ある8 | 16 | 4の値を有します。今

Detached = 1, 
Unchanged = 2, 
Added = 3, 
Deleted = 4, 
Modified = 5 

EntityState.Deleted | EntityState.Modified | EntityState.AddedEntityState.Detached | Entity.Unchanged | Entity.Deletedと同じである7の価値を持っているでしょう：ちょうどインクリメント値があればそれは動作しません。

FlagsAttributeは、後者ではなく前者のアプローチを取っていることを示すメタデータを提供するために使用されるため、マスキングが機能します。タイプ自体に直接影響を与える唯一の効果は、ToString()の仕組みにあります。これは、このアプローチをとるときには意味がありません。

Answer 2

内部的には、EntityStateも複数の状態を含める/除外するために使用されます。 ObjectStateManagerで例えば

、：ObjectContextで

IEnumerable<IEntityStateEntry> IEntityStateManager.GetEntityStateEntries(EntityState state) 

は使用方法：

var entriesAffected = ObjectStateManager.GetObjectStateEntriesCount(EntityState.Added |     
                    EntityState.Deleted | 
                    EntityState.Modified); 

APIのかかるポイント・オブ・ビューから、私はあなたが安全に、実際の状態と仮定することができると思いますエンティティはオプションの1つにしかなりません。