0

私はこのパターンについてググりすぎて、自分自身を混乱させていると思うので、あなたの意見をいただければ幸いです.

小さなアプリケーション用のデータベースがある場合、これは次のようになります。

  • 会社
    • 名前
    • 住所
    • テンプレートファイルパス
  • デパートメント
    • 名前
    • 住所
    • レポート番号
  • 事件
    • レポート番号
    • 位置
    • ドライバーの姓
    • 日にち

基本的に、モデル オブジェクトを JSON にシリアライズおよびデシリアライズするコードを既にいくつか作成していますが、コードは乱雑で密結合です。これは基本的に抽象化したいので、あとでDBを使うことになったときに、アプリケーションの成長に合わせて切り替えるのは比較的簡単です。

リポジトリを作成するとしたら (単一のリポジトリではないと思います)、メソッド シグネチャはどのようになりますか? インターフェイスを使用しますか? これが私が始めたことです：

IRepository<T>

  • Add(T Entity)
  • Delete(T Entity)
  • Update(T Entity)

ICustomerRepository : IRepository<Customer>

  • GetAllCustomers()
  • GetCustomerByName(string name)

IDepartmentRepository : IRepository<Department>

  • GetAllDepartments()
  • GetDepartmentByName(string name)

それから私は考え始めました、私は DRY コードを書くつもりはありません... 顧客と部門のリポジトリは基本的に同じことをしています.唯一の違いはメソッド名と実際の DB テーブルまたは情報が保存されているファイルです.私はそれを正しくやっていますか？

私が読んだことから、リポジトリは実際のストレージの単なるラッパーです。SQLite を使用している場合と同様に、リポジトリで接続を作成し、通常のコードでは Customer および Department クラスのみを処理し、SQL 接続またはデシリアライズの方法については何も知らず、リポジトリについてしか知りません。

4

2 に答える 2

0

いくつかの考え：

  • Update()ほとんどの場合、エンティティのグラフ全体の変更を一度に保存するのではなく、一度に保存する必要があるため、通常、リポジトリ レベルでは処理されません。これに対処する一般的な方法の 1 つは、アプリケーション サービス / ユース ケース レベルで作業単位を使用することです。これにより、ORM の変更トラッカーが活用される場合があります。

  • はい、たとえばテストでリポジトリをモックするなど、さまざまなリポジトリ実装をコンシューマーに挿入する場合は、インターフェイスが必要です。

  • インターフェイスの階層を前もって理解しようとする代わりに、私がやりたいのは、ニーズ主導のアプローチを取ることです。言い換えれば、Repository インターフェースは必要に応じて作成してください。単体テストでモック リポジトリとやり取りする必要があることに気付いた場合や、実稼働コードを作成している場合などです。クライアント コードがリポジトリを使用する方法によってインターフェイスが形作られ、これらのインターフェイスのそれぞれが実際に理由があることが保証されます。

于 2013-07-09T11:16:04.550 に答える