問題タブ [repository-pattern]

新しいasp.netWebプロジェクトを開始する準備をしており、LINQ-to-SQLを使用します。インターフェースとジェネリックを使用してデータベース内の各テーブルのリポジトリを作成するMikeHadlowが見つけた情報を使用して、データレイヤーのセットアップを取得するために少し作業を行いました。最初はこれが面白いアプローチだと思いました。ただし、今では、基本リポジトリクラスを作成し、それを継承して、アクセスする必要のあるテーブルのTableNameRepositoryクラスを作成する方が理にかなっていると思います。

クリーンでテスト可能な方法でテーブルに固有の機能を追加できるのはどのアプローチですか？これが参考のために私のリポジトリの実装です。

ASP.net MVC アプリケーションのドメイン駆動設計原則に従うリポジトリ パターンの実装例/リソースを探しています。誰かが共有できる良い例や学習リソースを持っていますか?

私はリポジトリを書いています。オブジェクトのフェッチは、DAO を通じて行われます。オブジェクトの作成と更新は、RequestHandler オブジェクトに渡される Request オブジェクトを介して行われます (コマンド パターンのように)。DAO、Request、または RequestHandler を作成していないため、変更できません。

このリポジトリのテストを作成しようとしています。DAO と RequestHandler の両方をモックアウトしました。私の目標は、モックされた RequestHandler が、新しいオブジェクトまたは更新されたオブジェクトをモックされた DAO に単純に追加することです。これにより、DB と話しているような錯覚が生まれます。このように、このリポジトリを呼び出すすべてのクラスのリポジトリをモックする必要はありません。

問題は、Request オブジェクトが文字列の塊とさまざまな英数字コードの塊であることです。XMLも関係していると確信しています。それは一種の混乱です。別の開発者が、格納されているオブジェクトに基づいて Request オブジェクトを作成するコードを作成しています。また、RequestHandler は、保存しているオブジェクトではなくリクエストを受け取るため、モックされた DAO を更新できません。

問題は、リクエストもモックするか、それとも遅い人がコードを書き終えるまで待ってからテストを書くべきかということです。それとも、リポジトリを呼び出すクラスをテストするときに、それを台無しにしてリポジトリ全体をモックアウトしますか?

ところで、「モック」とは NMock の意味ではなく、メモリ内コレクションで DB を偽造するようなものです。

リポジトリ パターンに目を通したところ、過去に使用していたいくつかのアイデアに気づき、気分が良くなりました。

ただし、このパターンを使用するアプリケーションを作成したいと考えていますが、エンティティ クラスをリポジトリ プロバイダーから切り離したいと考えています。

私はいくつかのアセンブリを作成します：

1. IRepository インターフェイスを含む共通インターフェイスをホストする「インターフェイス」アセンブリ
2. Product、User、Order などのエンティティ クラスをホストする「エンティティ」アセンブリ。一部のメソッドはそのような型またはそれらの配列を返すため、このアセンブリは「Interfaces」アセンブリによって参照されます。また、メイン アプリケーション アセンブリ (Web アプリケーションなど) によっても参照されます。
3. 1 つ以上のリポジトリ プロバイダー アセンブリ。それぞれに (少なくとも) IRepository インターフェイスを実装するクラスが含まれ、特定のデータ ストアで動作します。データ ストアには、SQL Server、Oracle サーバー、MySQL、XML ファイル、Web/WCF サービスなどを含めることができます。

すべてを実装するのにかかる時間の点で非常に生産的に見える LINQ to SQL を研究することは、生成されたクラスと CustomDataContext クラスの間の深い依存関係を発見するまではうまくいくようです。

このようなシナリオで LINQ to SQL を使用するにはどうすればよいですか?

正規の Customer ドメイン オブジェクトがあるとします。顧客が表示される 3 つの異なる画面があります: 外部管理者、内部管理者、およびアカウントの更新です。

さらに、各画面には Customer オブジェクトに含まれるすべてのデータのサブセットのみが表示されるとします。

問題は、UI が各画面から (たとえば DTO を介して) データを返すときに、完全な Customer ドメイン オブジェクトのサブセットのみが含まれていることです。したがって、Customer オブジェクトを再作成するためにその DTO を Customer Factory に送信すると、Customer の一部しか得られません。

次に、この顧客を顧客リポジトリに送信して保存すると、そこにないため、大量のデータが消去されます。悲劇が起こります。

問題は、この問題にどのように対処するかです。

私のアイデアのいくつか：

• 顧客のどの部分を更新するかを示す引数をリポジトリに含め、他の部分を無視する

• 顧客をロードするときは、静的メモリ、セッション、またはどこにでも保持し、UI から DTO の 1 つを受け取ったら、DTO に関連する部分のみを更新します。

IMO、これらはどちらもクラッジです。他に良いアイデアはありますか？

@chadmyers: ここに問題があります。

エンティティにはプロパティ A、B、C、および D があります。

DTO #1 には、B と C のプロパティが含まれています。

DTO #2 には、C および D のプロパティが含まれています。

UI は DTO #1 を要求します。エンティティをリポジトリから読み込み、DTO #1 に変換し、B と C のみを入力して、UI に渡します。

ここで、UI は B を更新し、DTO を送り返します。エンティティを再作成すると、DTO に含まれているのは B と C だけなので、B と C だけが入力されます。

次に、B と C のみが入力されたエンティティを保存し、A と D を null/空白にします。リポジトリは、A と D を空白として永続的に更新する必要があるかどうか、またはそれらを無視する必要があるかどうかを知る方法がありません。

簡単な質問: ドメイン駆動型のデザイン スタイルのリポジトリをシングルトンとして実装することは、良い考えですか、それとも悪い考えですか? なんで？

それとも、依存性インジェクター コンテナーを使用してリポジトリを管理し、それらがシングルトンかどうかを判断する必要がありますか?

私はまだDDD Quicklyを読んでいて、いくつかの良いリポジトリの例を見たいと思っています。

私は MVC フレームワークをしばらく使用していますが、懸念事項がどのように分離されているかが本当に気に入っています。私は、コントローラーにかなりの作業を任せるという悪い習慣に陥っています。だから私は本当にいくつかのアドバイスを探しています。

私が MVC を使い始めた当初は、データベースの作業が完了した後で、コントローラーがモデルを操作することがよくありました。私はこれが悪いことを知っていたので、モデルに働きかけました。ただし、モデルを非常に学習させたいので、これには満足していません。

私は少し読んだことがありますが、私が気に入っているサービスレイヤーを使用することで、人々がコントローラーとモデルをスリムに保っていることがわかります。

サービスレイヤーとリポジトリがどのように連携するかを理解しようとしています。これが私の仮定です。これが良い方法であるかどうか教えてください。

1. データに対して操作を行う必要がなく、そのようなサービス層が関与する必要がない場合、コントローラはリポジトリを直接呼び出すことができます。
2. データ (ビジネス ロジック) に対して何らかの作業を行う必要がある場合、これはサービス レイヤーで実行する必要があり、コントローラーは必要に応じてサービス レイヤーへの単純な呼び出しを行います。
3. サービスがビジネス ロジックを完了すると、必要に応じてリポジトリが使用されます (データを永続化する必要がある場合)。
4. モデルは理想的には無駄のない状態に保ち、理想的には DTO に過ぎないものとして機能する必要があります
5. データの検証はモデル内で行われます (MonoRail 検証属性を使用)。多くの属性でモデルを汚染するのが好きな人はいないと思いますが、それは別の議論です. UI での自動 jQuery 検証に対する MonoRail の検証属性の利点が気に入っています。

私はすべてのコードを単一責任の原則に変えようとしているため、コーディングの慣行を整理しようとしています。

ありがとう

誰かがこれを行う方法をもっとよく考えているかどうか疑問に思っていました。私には汚れているように見えるように戻っIQueryable<Member>てくるatm 。ObjectQuery<Member>

さまざまなタイプのオブジェクトを追加、検索、更新、および削除できる汎用リポジトリ インターフェイスを使用しています。次に、2 つの具体的なリポジトリを実装し、アプリケーションを変更せずにそれらを切り替えることができます。すべてが見事に切り離されています。しかし、私は思わぬ障害にぶつかりました。リポジトリ メソッド内のコードが間違っているように感じ、それを改善する方法がわかりません。ここに私のコードのスニペットがあります:

問題は、私の DataAccess (データリーダーからオブジェクトを作成する) が一般的ではなく、サポートするオブジェクトの種類ごとに特定のメソッドを持っていることです。

上記を書き直して、ジェネリックなどを使用して if-then-elseif のリストを回避できますか?

私は ASP.NET MVC や SOLID などについていくつか読んできましたが、これらの概念をまとめた小規模から中規模の ASP.NET MVC アプリの簡単な "レシピ" を見つけようとしています。私が最も懸念している問題は、コントローラーが複雑すぎて、Web フォームのコード ビハインド ファイルのようになり、あらゆる種類のビジネス ロジックが組み込まれることです。

小さなデータ駆動型アプリの場合、次のアーキテクチャを検討しています。

• コントローラー: リクエストのみを処理し、適切なサービスを呼び出して、アクションの結果をビューに返します。
• モデル: POCO、すべてのビジネス ロジック、承認などを処理します。リポジトリに依存し、永続化インフラストラクチャをまったく知りません。
• リポジトリ: 実装しIRepository<T>、依存性注入を使用し、私のデータベース コードが存在する場所です。POCOを受け取り、返すだけです。

コントローラーとモデルの間にサービスを配置することを検討していますが、メソッド呼び出しを転送するだけの場合、それがどれほど役立つかわかりません。

最後に、モデル コードをカバーする単体テストと、リポジトリ コードをカバーする単体テストと統合テストが必要です (可能であれば、「レッド グリーン」プラクティスに従います)。

考え？