タグ付けされた質問 「repository」

多くのGitHubアカウントには、他のアカウントから分岐されたリポジトリしかありません。さらに、これを行う人々は通常、フォークされたリポジトリに貢献しません。 切手や貝殻を収集する人のことを聞いたことがありますが、なぜリポジトリを収集したいのでしょうか？個人的には、リポジトリに変更を加えたい場合にのみ、リポジトリをフォークします。

110 github  repository  forking 

コントローラがサービスの代わりにリポジトリを呼び出すのは悪い習慣ですか？ さらに説明する： 優れた設計では、コントローラーがサービスを呼び出し、サービスがリポジトリを使用することがわかります。 ただし、コントローラーにはロジックがない場合や必要ない場合があり、dbからフェッチしてビューに渡すだけでよい場合があります。 そして、私はリポジトリを呼び出すだけでそれを行うことができます-サービスを呼び出す必要はありません-それは悪い習慣ですか？

43 design-patterns  object-oriented  mvc  repository 

最近、リポジトリパターンをORMと組み合わせて使用​​するのは良い習慣ではないことを読みました。私の理解から、これはSQLデータベース上で提供する抽象化がパターンに含まれるには漏れやすいためです。 これについていくつか質問があります。 ORMを切り替えたい場合はどうしますか？リポジトリに含まれていない場合、アプリケーションにORM固有のコードが含まれます。 ORMを使用せず、データアクセスとオブジェクトデータの入力にADO.NETを使用している場合、リポジトリパターンはまだ有効ですか？ リポジトリパターンではなくORMを使用する場合、よく使用されるクエリはどこに保存しますか？各クエリをクラスとして表現し、インスタンスを作成するための何らかのクエリファクトリを用意するのが賢明でしょうか？

20 design-patterns  orm  repository 

リポジトリパターンの多くを聞いたことがありますが、リポジトリが実際に何をすべきかを理解していませんでした。「リポジトリが実際にすべきこと」と言うとき、私は主にどのメソッドを提供すべきかを心配しています。たとえば、リポジトリは本当にCRUDメソッドを提供する必要がありますか、それとも何らかの種類のメソッドを提供する必要がありますか？ つまり、リポジトリにビジネスロジックを含めるべきですか、それとも単にデータストアと通信し、保存またはロードするエンティティを管理するためのロジックを含めるべきですか？ また、リポジトリは集約の永続性の単位であると聞いています。しかし、それはどうですか？これが実際にどのように機能するのか理解できません。IRepositoryCRUDメソッドを含むインターフェイスを1つだけ持つ必要があると考えました。その後、エンティティには、そのような型をデータストアから保存および取得するためのロジックが含まれます。

15 design-patterns  object-oriented-design  repository 

-repositoryデータベースからデータを取得するために、接尾辞が付いた一連の個別のクラスを使用しています。各テーブルごとに独自のリポジトリ。 たとえば、customerrepository顧客を取得するためのあらゆる種類のメソッドを持つクラスと、vacancyrepository空席を取得するためのあらゆる種類のメソッドを持つクラスがあります。 このことを行う方法について2つの質問があります。 複数のテーブルにまたがるデータを取得するのはどうですか？たとえば、私はまだ空席を作成していないすべての顧客を表示する画面を持っています。のcustomerrepositoryメソッドを使用できますか、vacancyrespository両方のリポジトリが結果を返すdataserviceことができますか？両方のリポジトリから結果を取得して1つの結果に結合する階層の上位にクラスを付けますか？ そのようなリポジトリはどのくらいのロジックを処理できますか？ リポジトリに「where active == true」を実装してアクティブなレコードのみを取得してもよいと思いますか、またはその単純なロジックでさえ、階層の上位のクラスで処理する必要があります（名前を付けましょうdataservice）？ 私が今遭遇した例はこれです： 1つ以上の質問を含む質問リストがあります。 質問には結果があり、別のテーブルに保持されます。 したがって、質問リストの合計結果を取得するには、questionlistテーブル、質問テーブル、およびテーブルのデータを結合する必要がありquestionstatusます。 現在、これらのテーブルには3つの異なるリポジトリがあります。 questionlistrepositoryリスト番号12の合計結果を尋ねると、他の2つのリポジトリからデータを取得する必要があり、そのため何らかのロジックが必要になります。 またはquestionlistdataservice、使用するリポジトリを知っているものはありますか？ もう1つ：リポジトリは結果を生成できるIQueryableため、呼び出し元のサービスは結果を簡単に結合できますが、そうでない場合は、3つのテーブルすべてのコンテンツをすべて取得することは良い考えではないと思いますデータベース。

14 c#  design  design-patterns  repository 

タスクログシステムがあるとします。タスクがログに記録されると、ユーザーはカテゴリを指定し、タスクはデフォルトで「未処理」のステータスになります。このインスタンスでは、CategoryとStatusをエンティティとして実装する必要があると想定しています。通常、私はこれをします： アプリケーション層： public class TaskService { //... public void Add(Guid categoryId, string description) { var category = _categoryRepository.GetById(categoryId); var status = _statusRepository.GetById(Constants.Status.OutstandingId); var task = Task.Create(category, status, description); _taskRepository.Save(task); } } エンティティ： public class Task { //... public static void Create(Category category, Status status, string description) { return new Task …

14 architecture  domain-driven-design  repository  domain-model  entity 

ソフトウェア開発の一般的なシナリオは、誰かのコードをレビューするコードです。これを行う一般的なツールは、プルリクエストを開くことです。 私の質問は、レビューで問題が見つかったときに、変更すべきかどうかです 個別にコミットする（新しいコミット） または、既存のコミットを変更する必要があります（以前のコミットから誰もブランチしていないと仮定します...共有ブランチからの履歴を書き換えることは悪いニュースです）。 最初のシナリオでは、コミット履歴にノイズを追加しますが、増分の変更を追跡するのは簡単です。2番目のオプションには、長所と短所が逆になっています。

11 git  code-reviews  repository 

イベントソーシングと一緒にCQRSパターンを使用して、最初のアプリケーションを実装します。集約ルートの作成を適切に処理する方法について疑問に思っています。誰かがCreateItemコマンドを送信したとしましょう。どのように処理する必要がありますか？イベントItemCreatedを保存​​する場所 新しいアイテムの最初のイベントとして？または、すべてのアイテムを集約し、そのイベントリストがItemCreatedイベントのみで構成される、何らかの種類のItemListエンティティが必要ですか？ Udi Dahan は、集約ルートを作成せず、常に何らかのフェッチメソッドを常に使用することを提案しています。しかし、新しいもので、IDが割り当てられていないものを取得する方法。私は背後にある考え方を理解しており、新しいオブジェクトは、それに応答するイベントがゼロで構成される状態を持つオブジェクトであると考えるのはかなり合理的です。しかし、どのように使用すればよいですか？私のような私のリポジトリに明確な方法を持っていなければならないgetNewItem()か、私の作るget(id)方法を受け入れてOptional<ItemId>代わりに？ 編集：しばらく掘り下げた後、アクターを使用した前述のパターンの非常に興味深い実装を見つけました。作成者は、集計を作成する代わりに、新しく作成されたUUIDを使用して、何らかの種類のリポジトリからそれを取得します。このアプローチの欠点は、一時的な不整合状態を許容することです。またdelete、このようなアプローチでメソッドを実装する方法を疑問に思っています。削除済みイベントを集約のイベントリストに追加するだけですか？

11 domain-driven-design  repository  cqrs  event-sourcing 

GitHubで少なくとも3つのリポジトリを含むプロジェクトを開始しました。 リポジトリの1つは、一般的なドキュメントとサンプルのダンプであり、他の2つのリポジトリには、プロジェクトのバックボーンを形成する2つのプログラムの実装が含まれています。 このような構成を処理するためにGitHub組織を使用する必要がありますか？または、完全に無関係な他の12個のリポジトリとともに、すべてを自分のアカウントにすべてダンプする必要がありますか？

11 git  github  organization  repository 

中規模のMVC Webアプリケーションのアーキテクチャを計画するとき、レイヤーを可能な限り分離してテストしやすいように実装するにはどうすればよいですか？（基本的にベストプラクティスに従います）データアクセスとして最初にコードを使用しているとしましょう。 「ビジネスロジック」の定義、およびデータレイヤーとのやり取りをどのように定義するかについて、私は苦労しています。車両販売アプリケーションを例にとると、ビジネスロジックは、特定の車両の税帯の計算、ガロンあたりのマイル統計の比較などのタスクを実行するクラスでしょうか。ビジネスエンティティ（例：車、バン、オートバイ）については、これらをDataContextクラスと共にデータレイヤーに配置します。 また、ビジネスとは対照的に、アプリケーションロジックを構成するものは何ですか。セッション/ユーザー入力の検証などを推測していますか？ したがって、たとえば、車のコントローラは、タイプと最良のmpgでフィルタされた上位10台の車をリストするアクション/ビューの結果を返す場合があります。たとえば、ICarRepository「リポジトリ」/ DIを使用して「carRepo」をコントローラに注入したとします。アクションメソッドのパラメータから車をフィルタリングします。var cars = carRepo.getCarsByType("hatchback"); したがって、リポジトリを使用してデータアクセスの知識をコントローラーから除外し、ドメインモデルを使用してビジネスロジックをコントローラーから除外しました-var result = new MpgCalculator（cars）; -DBからエンティティをロード/フィルタリングするだけではなく、最高の燃料効率を計算するために追加のロジックを実行する必要があるため、電卓クラスが必要だとしましょう。これで、ビューをレンダリングするためのデータセットがあり、リポジトリを使用してデータアクセスレイヤーから取得し、ドメイン固有のオブジェクトを処理して、そのデータに対してビジネス関連のタスクを実行します。 ここで間違いをしていますか？それでもリポジトリパターンを使用する必要がありますか、それともORMを分離してテストするためにインターフェイスに対してコーディングするだけですか？このトピックでは、具体的なデータアクセスクラスdbcontextがデータレイヤーにあるので、インターフェイス定義をドメイン/ビジネスレイヤーに入れる必要があります。つまり、データアクセステクノロジーが変更されても、他のレイヤーは影響を受けません。 これまでに調べたことから、私の構造は次のようになります。 MVCインターネットアプリケーション ->標準インターネットプロジェクト-ここのモデルはViewModelsです ドメイン/ビジネスレイヤー ->コントローラーが関連するビューに渡す前にデータレイヤーからドメインエンティティを処理するために使用できるビジネス固有のクラス/モデル リポジトリの抽象化が必要ですか？->特にORMを使用する場合、これについて多くの議論が聞こえます データレイヤー ->エンティティクラス（Car、Van、Motorcycle）、DbContext-具象データアクセステクノロジーレイヤー

11 design-patterns  mvc  asp.net-mvc  repository  n-tier 

私の新しいプロジェクトでは、TDDを試すことにしました。そして、最初に問題が発生しました。アプリケーションで最初にしたいことは、データソースからデータを読み取る機能を提供することです。この目的のために、私はリポジトリパターンを使用したいと思います。そしていま： テストがリポジトリー・インターフェースの実際の実装を対象としている場合、私はデータベースにアクセスできるクラスをテストしますが、それは避けなければならないことを知っています。 テストがレポジトリパターンの実際の実装ではない場合、私はうまくテストします...ただ模擬します。これらの単体テストでテストされる製品コードはありません。 私はこれを2日から考えていますが、それでも適切な解決策を見つけることはできません。私は何をすべきですか？

10 tdd  patterns-and-practices  repository 

ドメインドリブンデザインについて初めて知ったとき、データベースに対する穴居人のようなSQLクエリを投げたクールな子供たちにとって、かつては一流であるように思われるリポジトリと作業単位パターンも紹介されました。EFやNHibernateのようなORMは、作業単位とリポジトリの両方を1つのAPI（セッションまたはコンテキストと呼ばれる）に実装するため、そのトピックを深く掘り下げれば読むほど、それらは必要なくなったように見えます。 今、私は何をすべきかわかりません。リポジトリするかしないか。このようなリークの多い抽象化は複雑すぎてデータアクセスを簡略化するものは一切追加しないという主張を本当に理解していますが、アプリケーションのあらゆる側面をEntity Frameworkなどに結合するのは適切ではないと感じます。通常、私はいくつかの簡単なガイドラインに従います： ドメイン層は、エンティティ、サービス、リポジトリを含むシステムの中心です... インフラストラクチャ層は、ファイル、データベース、プロトコルなどのインフラストラクチャ関連のドメインインターフェイスの実装を提供します。 アプリケーション層は、物事を結び付け、すべてをオーケストレーションするコンポジションルートをホストします。 私の解決策は通常次のようになります： Domain.Module1 Domain.Module2 IModule2Repo IModule2Service Module2 Infrastructure.Persistence Repositories EntityFrameworkRepositoryBase MyApp Boostrapper -> inject EntityFrameworkRepositoryBase into IRepository etc. 私は、IRepository<'T>データへのアクセス方法を教えてくれる他のものに依存しないドメインの問題でもあるを使用して、ドメインレイヤーをクリーンに保ちます。IModule2Serviceデータアクセスを必要とする具体的な実装を行うときは、注入DbContextし、これによってインフラストラクチャレイヤーに直接結合する必要があります。（Visual Studioプロジェクトに入ると、循環依存関係のために、これは本当にトリッキーになる可能性があります！） さらに、作品の保管庫やファックトンの代わりになるものは何ですか？CQRS？純粋なインフラストラクチャフレームワークを抽象化するにはどうすればよいですか？

10 design-patterns  database  domain-driven-design  dependency-injection  repository 

DAO、DAL、ドメイン駆動設計などのコンセプトは初めてです。最後に、パーシスタンスレイヤー（mysqlデータベース）を、Webアプリケーションのビジネスオブジェクトおよびロジックから切り離したいと考えています。DAOのコンセプトは気に入りましたが、他のエンティティが関連付けられているデータベースからビジネスオブジェクトを作成しようとすると、DAOの実装に行き詰まりました（dbテーブルの外部キーで表されます）。 これらの参照（集計）はDAOパターンを使用してどのように処理されますか？すべてのオンラインDAOの例は単純で、（他のエンティティや値オブジェクトを参照せずに）値オブジェクトのようなビジネスオブジェクトのみの作成を示しています。依存性注入を使用して行われますか？そうであれば、依存関係はどこに作成されますか？ さらに読むことで、DDDからのリポジトリパターンは、バックグラウンドでDAOを使用し、オブジェクトの集約を処理する可能性を与えると思います。私が理解しているように、それはいわゆるルート（すべての参照がロードされたエンティティまたはレイジーロードされたエンティティ）を外界に提供するだけです。DAOの使用時にリポジトリは推奨されますか、それともDAO自体がビジネスオブジェクトに対する永続性の無知を維持することによってこの機能を提供できますか？ 私はORMツールを使用しておらず、これらの基本的なパターンを直接探求したくはありません。

10 repository  entity  dao 

私が学んだ限り、にはIRepositoryが含まれている必要がありますCRUD。その後、我々はこれを継承するIRepositoryような当社の他のインターフェイスにIProductして実装するIProduct具象クラスをProductRepository、などの方法でGetAllProducts()、Top5Products()。 n層アーキテクチャでも同じことができます。作成、のようにDAL Class Library、そこにクラスを定義するProductような方法でGetAllProducts()、Top5Products()。 両方において、DAL.ProductそしてRepo.ProductRepository、我々は初期化したクラスDB ContextでEntity Framework、当社の関連データを照会します。 呼び出しは両方Repo.ProductRepositoryまたはDAL.Productメソッドから似ていますBLL これらの類似点を考慮して、私の質問はレポの利点は何ですか？私はn層アーキテクチャを使用して非常に簡単に同じことを行うことができます（Controller、BLL Class Library、DAL Class Library）。

9 design-patterns  architecture  repository  n-tier  repository-pattern 

EFチームにgithubで質問を投稿しました。ここでこの質問をする方がよいとの返信がありました。コピーしてここに貼り付け、リンクとして他のユーザーがGitHubでいくつかの返信を確認できるようにします。 質問：私はいくつかの調査を行っていましたが、誰かがDBContextクラスの24行目で次のように述べていると指摘しました DbContextは、作業単位パターンとリポジトリパターンの組み合わせです。 これは、EFをリポジトリーに抽象化し、インターフェースを使用してそれをコントローラーに注入する必要がなくなったことを意味しますか？ Githubの元の投稿：https : //github.com/aspnet/EntityFramework/issues/4899 私がこれを尋ねる理由は、GetById、GetByName、GetWithIncludesABC、GetWithIncludes123などの多くのメソッドをリポジトリに追加しているように見えて、私の心の中でリポジトリを汚しているように思われるからです。

9 asp.net-mvc  entity-framework  repository