問題タブ [repository-pattern]

ASP.NET MVCとC＃を使用して複数のデータベースレイヤーをサポートできるリポジトリのスケルトンデザインはどのようになりますか？LINQtoSQLとNHibernateの両方をサポートした場合のデザインがどのようになるかを確認したいと思います。データベースオブジェクトを作成し、BLLレイヤーでそのオブジェクトのメソッドを呼び出すにはどうすればよいですか？

コードを整理しようとしています。サービス層、つまり DLL への参照を持つプロジェクトがいくつかあります。これが意味することは、新しいサービス レイヤーを配布するときに、通常は同じ多数のサービス レイヤーをアップロードする必要があるということです。

もちろん、ADD Reference を使用すると、あるアセンブリが別のアセンブリと通信するため、非常に高速です...

別の方法の長所と短所を知りたかった..

Web サービス/wcf を使用してサービス レイヤーをラップできますが、これはオブジェクトを無効にするものではありません..

速度についてはどうでしょうか。デスクトップ アプリケーションは、アセンブリ参照にアクセスする代わりに、Web サービス/wcf を呼び出す必要がありますか??

私のサービスレイヤーはもちろん私のデータレイヤーと通信し、クライアントはデータレイヤーと直接通信することはありません..

私のビジネスロジックがいくつかのアプリ間で共有されているサービスレイヤーの問題です..

デスクトップ アプリ、2 つの Web サイト、2 つの wcf プロジェクト (Web サービスとして使用)

コードを繰り返さずに最速のシナリオを達成する方法についてのアドバイス。つまり、現在行っていることに影響します。

各アプリ (デスクトップ、Web サイト、wcf) は同じ DLL にコピーがあり、参照があります (vs 2008 で参照を追加します) ..

アイデア？

.NET 1.1（C＃）でリポジトリパターンを使用するための一般的なアプローチは何ですか？

私はこのStackOverflowの質問に沿って何かを探していますが、.NET 1.1にはジェネリックがないので、それが可能かどうかを調べています（確かにそうです）。それが通常どのように行われるか。

リポジトリパターンの例をたくさん見つけました。それらはすべて、リポジトリが独自の接続ライフサイクルを管理していることを示しています。複数のリポジトリ間で単一の接続を共有したい場合、人々はどのように対処するのだろうかと思いました。

私が尋ねている主な理由は、TransactionScopeを使用してトランザクションを作成するときに、DTCトランザクションにエスカレートしたくないからです。セットアップは簡単ですが、少し重いようです。

私が考えていたのは、接続のライフサイクルを管理するTransactionScopeに似たものを使用することでした。ただし、データアクセスをビジネスプロセスに少しリンクしているようです。私が言っていることの例は次のとおりです。

かなり標準的なリポジトリパターンがあり、構築時にリポジトリがMVCコントローラーに注入されます。リポジトリはAppDomainごとに1回初期化され、他のコントローラーによって共有されます。リポジトリはNHibernateISessionsとICriteriaを使用してデータベースにアクセスしますが、アクセスはICriteriaを直接受け入れるのではなく、ListXYZメソッドを使用して公開されます。

私は今、証明書の場合に返される結果を制限するためのきちんとした方法が必要です。そのようなものの1つは、たとえば、アクションが呼び出されたときにのみ知られる、特定の市場のすべての製品をリストすることです。

ListXYZメソッドを呼び出すたびに、この制限を渡したくありません。これは、多くのオーバーロードされたメソッドにつながるためです。理想的には、以前と同じようにリポジトリにアクセスできるようにしたいのですが、制限が適用されています。何かのようなもの：

何か提案はどうすればいいですか？それとも私はそれを自分にとって複雑にしすぎていますか？

リポジトリ パターンで独自のモデル クラスを使用したいと考えています。LINQ to SQL が生成するクラスに依存したくありません。それは実行可能ですか？(とLINQ to SQL が必要なWhere場合のその他の選択を処理するにはどうすればよいですか?Func<MyModel, bool>Func<LinqToSqlModel, bool>

私はこれを考案しましたが、私はそれをオーバーエンジニアリングし始めているかもしれません...

これはリダイレクトが多すぎますか?

私がやりたいのはMyModel、LINQ to SQL、LINQ to Enities など、バックエンドで実装できるリポジトリを用意することだけです。リソースはありますか?

外部アセンブリに存在するリポジトリとモデルを共有する2つのasp.net mvcプロジェクトを含む、いくつかのプロジェクトを含むソリューションがあります(これも同じソリューションにあります)。本質的に...

コア/
-リポジトリ -
モデル

Domestic.Web/
-Basic MVC サイト、コア プロジェクトを参照

International.Web/
-基本的な MVC サイト、コア プロジェクトを参照

私がやりたいことは、すべてのデータベース管理者向けの Silverlight 3 / RIA Services アプリケーションを構築することです。RIA サービス (ほとんどの場合) が実際には Entity Framework でしか文書化されていないことを除けば、それで問題ありません。Linq2Sql に関する情報を見つけることができます。

私が必要としているのは、POCO で RIA を使用する際の最良のリファレンスですが、MVC / Nerddiner スタイルのリポジトリ パターンでの使用に関するドキュメントがあればなおさらです。

ありがとう！

リポジトリパターンに基づいてドメインモデルを開発していますが、TDDの一部としてのすべての単体テストがテストリポジトリに対して実行されています。

私の質問は、SQLバージョンのリポジトリに対して統合テストを作成するのはどの時点ですか？

私の懸念は、オブジェクト（テストリポジトリ）からデータにアクセスするためのコードが正常に機能することです。しかし、データベースのバージョン（SQLリポジトリ）は内部で非常に異なるため、SQLリポジトリ内の重要なコードは機能せず、それ自体はテストされません。意図したとおりに機能していることを確認するにはどうすればよいですか？プロセスについて何かが足りませんか？

よろしく。

Repository PatternASP.NET MVC アプリケーション (.NET 3.5、ASP.NET MVC 1.0、および Entity Framework を使用) を開発しているときに、を理解しようとしています。依存性注入を取得し、すべてが 1 つのコントローラーと 1 つのエンティティー型で機能するのに十分な距離まで到達しましたが、今では、異なる型間の関係のサポートを実装するところまで到達しており、行き詰まっています。

私が見たすべての例では、リポジトリ インターフェイスは のような名前で、アイテムのみIContactsRepositoryに関係する (CRUD) メソッドが含まれています。Contactのグループ化を実装したいContactsので、 というエンティティ タイプとGroup、IGroupRepositoryグループに対する操作 (CRUD) を処理するためのインターフェイスがあります。

• 複数のエンティティ タイプに関係するメソッドはどこに属しますか (この場合、たとえば、 aに aAddToGroupを追加するメソッド)。ContactGroup

リポジトリのより大きな継承構造を試み、次のインターフェイスを作成しました。

IRepository次に、次のように、を継承するマスター リポジトリを作成しようとしました。

このコードを使用して、コントローラからリポジトリ内のメソッドの 1 つを呼び出そうとするとすぐに

経由でGet<Contact>()継承されたものと経由で取得されたもののあいまいさに関するビルド エラー メッセージが表示されます。は異なるタイプの同じジェネリック インターフェイスを継承するため、これは許可されないことを理解しました (リンクされた記事の例 5 を参照)。IContactsRepositoryGet<Group>()IGroupsRepositoryIRepository

• 今、私は他のインターフェースを介して継承しているので、たとえば以下のように、これらのメソッドの「名前をオーバーライド」できる可能性はありますか?

  /li>

そうすれIRepository.Getcontactsば、あいまいさなくアクセスできます。それは可能ですか、またはこの問題の回避策はありますか?

明確にするために、新しい質問：

• コントローラーからの呼び出しで、どのGet()メソッドが必要かを指定する方法はありますか?

• 1 つのエンティティ タイプだけでなく、多くのことを処理するリポジトリが必要であるという、最初の問題に取り組む最善の方法は何ですか?

編集:Repositoryからのクラスと呼び出しのコード例を追加しましたController。

殴打されて死んだと思われる方は、あらかじめお詫び申し上げます。私はここ数時間、ここSOで多くの優れた投稿を検索して読んだばかりですが、それでも混乱しています。

私の混乱の原因は、DTOとDDDおよびリポジトリです。POCOドメインオブジェクトにスマートを持たせ、リポジトリから取得したいと思います。しかし、それを機能させるには、いくつかのカプセル化ルールに違反する必要があるようであり、DTOを彼らの頭に向けることができるようです。

簡単な例を次に示します。カタログアプリケーションでは、パーツは他の多くのパーツを含むパッケージである可能性があります。したがって、Part POCOがIEnumerable<Part>を返す'GetChildren（）'メソッドを持つことは理にかなっています。それは、その途中でリストを使って他のことをするかもしれません。

しかし、そのリストはどのように解決されますか？リポジトリが答えのようです：

と

そのため、私のカタログの利用者は、リポジトリからパーツを（正しく）ロードすることに加えて、GetChildren（part）を直接呼び出すことで、パーツでカプセル化されたロジックをバイパスすることもできます。悪くないですか？

リポジトリはPOCOを提供する必要があるが、DTOは「レイヤー間」でデータを転送するのに適していることを読みました。多くの部品プロパティが計算されます。たとえば、価格は複雑な価格設定ルールに基づいて計算されます。価格はリポジトリからのDTOにも含まれません。したがって、価格データをWebサービスに戻すには、DTOがパーツを消費する必要があります。その逆ではないようです。

これはすでに長くなりすぎています。頭を緩めたところはどこですか？