9

リポジトリ パターンについて調べた例には、エラー処理が含まれていません。どうしてこれなの?たとえば、私はこれを持っているとしましょう:

public virtual TItem Insert<TItem>(TItem item) where TItem:class,new()
    {
        dbContext.Set<TItem>().Add(item);
        try
        {
            dbContext.SaveChanges();
        }
        catch (DbUpdateException)
        {

            return null;
        }

        return item;

    }

制約に違反したインスタンス。DbUpdateException をキャッチします...リポジトリ自体にない場合、このエラー処理はどこで行われますか?

4

2 に答える 2

9

適切に設計されたシステムでは、制約に違反することは決してありません。エンティティをよりスマートにします。たとえば、ブラインドの自動実装セッターを使用しないでください。

リポジトリは、データの検証を行う場所ではありません。適切な場所は次のとおりです。

  • 単純に「契約上の」制約をチェックしている場合、たとえば「数量は非負の整数でなければならない」または「null の顧客を渡さないでください」などの場合は、ロジックをエンティティ自体に入れます (必要に応じて、セッター、コンストラクター、または変更メソッドのいずれか)。 .
  • ビジネス ロジックをチェックしている場合は、そのロジックを抽象化する特殊なオブジェクト (必要に応じて DDD 仕様) に入れます。

これらの例外が発生するのは、単体統合テストを実行して失敗した場合のみです。これにより、データベースの制約がエンティティと一致していないか、エンティティが正しく実装されていないことが明らかになります。したがって、絶対にすべきではありませんcatch

于 2011-04-06T03:41:04.490 に答える
3

ほとんどの場合、リポジトリは例外処理について心配する必要はありません。リポジトリを消費しているクラスはそれを処理する必要があります。あなたの例では、挿入エラーが発生した場合に null を返したいのはなぜですか? 単に例外をスローするよりも明確ではありませんか?

たとえば、リポジトリを介してレコードを挿入し、新しい ID を出力したいとします。何らかの理由で挿入が失敗すると仮定します。

var myNewItem = myRepository.Insert(myItem);
Console.WriteLine("MyItem added with ID: {0}", myNewItem.ID);

質問のパターンに従って、失敗したNullReference場合、2 行目に例外が発生しInsertます。それは少し奇妙です。最初の行にあるのがより明確DbUpdateExceptionです。またInsert、有効なインスタンスを返すか、例外をスローするかのいずれかを常に期待できる方がよいでしょう。

于 2011-04-06T03:56:22.413 に答える