0

古典的な 3 層アプリケーションを想定しています。DAL には、T が POCO クラスを表す GenericRepository があり、Insert(T エンティティ)、Delete(T エンティティ)、Update(T エンティティ) などのメソッドが含まれています。次に、BLL (ビジネス ロジック クラス) に CustomerRepositor のようなものが含まれています。まあ、すべての権利。

次に、aspx ページをイメージします。

var customers = BLL.CustomerRepository.GetAll();
customers.First().Name = "some name";

すべての CRUD 操作に対して何らかの検証を実行できるようにするには、CustomerRepository.Update、Insert、または Delete メソッドを渡す必要があります。このように、すべてのビジネス ロジックは、私が説明したようには機能しません。

誰もこれについて考えたことがないことに注意してください。しかし、これは重要な問題だと思います。CRUD 操作のビジネス メソッドをバイパスできる場合は意味がありません。

何か不足していますか？

4

1 に答える 1

2

では、始めましょう。

var customers = BLL.CustomerRepository.GetAll();

これは、過去 1000 年間の素晴らしいコード行でした。ジェネリックとLINQが登場する前。真剣に。

最近では、少なくとも次のようになると思います。

var customers = BLL.Repository<Customer>.ToList (); //IF you have to materialize

「All」メソッドはまったく必要ありません;）

何か不足していますか？

あなたがまだアプリケーション内にいることを大部分理解しているので、妥協はある程度受け入れられます。ここでアプリケーション間の信頼境界を実行するわけではありません。第二に、より良い抽象化をプログラムするべきだったという事実。

Repository repository = BLL.GetRepository ();
var customer s repository.Entity<Customer>.ToList ();
customer[0].Name = null;
repository.ValidateU ();
repository.Commit ();

はるかに優れた抽象化になります。作成は「新規」ではなく、

var newCustomer = repository.Create<Customer> ();

次にコミットします。

すべての検証は、Validate メソッドで確認できます。

最後に、これはリポジトリ用のインターフェイスをどのように設計するかについてです。状態を保持しないと主張すると (一部の操作では有効なパターンです)、問題が発生します。はい、完全な検証を行わないリポジトリを持つことができます-完全に有効です。それは本当に依存します。驚かれるかもしれませんが、私はほとんどの場合、パフォーマンス上の理由からリポジトリがオブジェクトと同じトランザクションで更新されることさえないアプリケーションで作業しており、更新はキューに入れられてからバッチ処理されますが、インメモリ バージョンはそれ以降のすべてに関連するものです。オペレーション。

最後に、DAL インターフェースの設計方法についてもう少し考える必要があることを示しています。完全に時代遅れで、メソッド クリープにつながるだけのアプローチの使用をやめてください (そうでなければ大量のメソッドが必要になるため)。ジェネリック + linq 式ツリーで消えるだけです。

于 2012-06-03T17:55:06.447 に答える