2

これを行うことは許容されますか？まず、エンティティを追加してみてください。追加が失敗した場合、それはエンティティがすでに存在することを意味するため、問題ではありませんか？

または、よりエレガントで簡単な解決策はありますか？

EntityFrameworkEntities dal = EntityDataModelHelper.GetEntityDataModel();

try
{
    dal.AddToXXXXXX(xxxxxxx);
}
catch
{

}

try
{
    dal.SaveChanges();
    return true;
}
catch
{
    return false;
}

OK私はそれを短縮しました...

EntityFrameworkEntities dal = EntityDataModelHelper.GetEntityDataModel();

if(xxxxxxx.ID == 0)
{
    dal.AddToXXXXXX(xxxxxxx);
}

try
{
    dal.SaveChanges();
    return true;
}
catch
{
    return false;
}
4

3 に答える 3

7

これを行うことは確かにOKではありません。C＃に型がないcatchステートメントは、「標準または非標準の例外をキャッチする」ことを意味します。ただし、追加の重複を防ぐことが目的です。追加は、既存のエントリを示さないさまざまな理由で失敗する可能性があります。たとえば、そのメソッドはnull参照をスローする可能性があり、それが追加されたと想定します。

重複した追加をチェックする場合は、重複した追加に対してスローされた例外のみをキャッチ する必要があります。

于 2009-03-13T17:22:23.047 に答える
1

IfExists スタイルのメソッドから始めて、実際に変更がない限り、変更の保存をスキップすることをお勧めします。

Lucas が指摘したように、try-catch ブロックは、catch ブロックに陥った場合に大きなオーバーヘッドが発生するため、通常、項目が既に存在するかどうかを判断する方法がない場合を除き、それに依存する必要はありません。

If ステートメントのジョブを実行するために try-catch を使用しないでください。try-catch は、予期しない異常なイベント用です。

編集 更新されたコードでは、「AddToXXXXXX」メソッドによってスローされる例外をキャッチできません。

やったほうがいい

If(!XXXXXX.Contains(newItemValue))
{
   try
   {
      add...
      savechanges...
   }
   catch
   {

   }
}

別の方法として、Add と Savechanges を別の try-catch ブロックに分離することもできますが、これは、Add が失敗した場合でも SaveChanges が実行される場合にのみ必要です。

于 2009-03-13T17:27:00.447 に答える
0

最初のTry-CatchをIfステートメントに置き換えることができますが、それでも2番目のステートメントが必要になると思います。

編集：また、例外が何であるかに関係なく、1つのブロックですべての例外をキャッチすることもお勧めしません。

PS Try Catchブロックは、Ifステートメントよりも多くの処理能力（時間）を使用します。

于 2009-03-13T17:23:23.013 に答える