1)機能を実装する唯一の手段でない限り、マジックストリングはできるだけ避けようとしています。
context
が(EF <= 4.0)の場合、通常、派生コンテキストに、名前などObjectContext
でを表すメンバーが必要です。次に使用できます:ObjectSet<Product>
Products
context.Products.AddObject(newProduct);
コンテキストにそのようなセットがない場合でも、別の強く型付けされたオプションがあります。
context.CreateObjectSet<Product>().AddObject(newProduct);
2)リターンタイプとしてボイドが発生しますが、インサートが良かったかどうかはどうすれば確認できますか?
AddObject
INSERTをデータベースに実行することはまったくありません。オブジェクトをAdded
objectContextの状態にするだけです。実際のINSERTは、後で.を呼び出すときに1つのトランザクションで発生しますSaveChanges
。
それでも、AddObject
同じキーを持つ2つのオブジェクトをコンテキストに追加した場合(エンティティにキーの自動生成IDがない場合)、またはその他の理由で失敗する可能性があります。その場合、AddObject
通常はコードに重大な問題またはバグがあることを示しているため、キャッチすべきではない例外がスローされます。
SaveChanges
を返しますint
。ただし、これは、オブジェクトの挿入が成功したことをint
示すものではありません。SQLステートメントが実行される前に、オブジェクトコンテキストで状態( INSERTステートメントが発生する)、状態(UPDATEステートメントが発生)、および状態(DELETEステートメントが発生)にあるオブジェクトSaveChanges
の数のみがカウントされます。Added
Modified
Deleted
繰り返しますが、SQLステートメント(INSERTなど)のいずれかが成功しなかった場合SaveChanges
、例外がスローされます。例外は、クライアント側ですでに問題が発生していることを示している場合もあれば、SQL操作中に問題が発生したことを示している場合もあります。たとえば、INSERTが失敗した場合、例外は、キーを持つ行がすでに存在するためにINSERTが失敗したというメッセージを表示する場合があります。データベースに挿入したい場合、または挿入したいエンティティにnull許容でない列が入力されていない場合など。また、他の多くの例外タイプの中で、同時実行の問題による例外が発生する可能性があります。
SaveChanges
考えられる例外をキャッチすることで、成功したかどうかを確認できます。
try
{
int numberOfObjects = context.SaveChanges();
}
catch (SomeExceptionType e)
{
// What now?
}
ところで:context.Products.Add(...)
あなたが見たのはおそらく(EF> = 4.1)でcontext
ある例でした。は、Entity Frameworkへの簡略化されたAPIです(これはまだ内部でコアを使用しています)。このAPIでは、新しいエンティティを挿入するメソッドは実際には(のメソッド)と呼ばれ、ではありません。DbContext
DbContext
ObjectContext
Add
DbSet<T>
AddObject