問題タブ [onion-architecture]

私はリポジトリパターンを実装しています。これの私の主な理由：

• 永続化の詳細からクライアント コードを抽象化するには (Entity Framework)
• テスト容易性をサポートする

汎用リポジトリかどうか?

私が遭遇した問題は、汎用リポジトリが必要かどうかです。メソッドは、特定のクエリを作成するIQueryable<T> Query()手段を呼び出し元のコードに提供します。ここでの問題は、これが漏れやすい抽象化であることです。Entity Framework の仕様がクライアント コードに漏れています。

• これは単体テストにどのように影響しますか? ICustomerRepositoryこの実装で モックを作成することはできますか?

• これは私の永続層を一掃することにどのように影響しますか? Azure Storage Tables や NHibernate と同様です。

そうしないとICustomerRepository、 や などの非常に特殊なクエリ メソッドを に実装する必要がGetIsActiveByFirstName()ありGetIsActiveByDistrict()ます。私のリポジトリクラスがさまざまなクエリメソッドでぎゅうぎゅう詰めになるので、これはとても嫌いです。このシステムには数百のモデルがあるため、作成および保守するこれらのメソッドが数百または数千になる可能性があります。

これは、ソリューションが部分的にどのように見えるかです。

私は Winforms 環境で Onion Architecture を使用しているため、UI、インフラストラクチャ、およびコア層があります。すべてのレイヤーは、依存性注入を使用して疎結合されています。私が達成したいのは、Accounts Forms (クラス ライブラリ) などのフォームがロードされるたびに、そのすべての依存関係を UnityContainer にロードする必要があることです。つまり、タイプを登録します。これらの依存関係は、コア プロジェクトとインフラストラクチャ プロジェクトに存在するインターフェイスと実装です。

私の混乱は、依存関係を登録するコードをどこに書くべきかということです? このアプリケーションの構成ルートは何ですか? Accounts Forms、HR Forms などのフォームはすべて、Base Forms Project のみを参照するメイン Windows アプリケーションのリフレクションを使用して読み込まれることに注意してください。

Eben Roux の提案の後

アセンブリがロードされたときにワイヤアップ コードを実行する方法は次のとおりです。

これは、WireUp メソッドを持つモジュールです。

だから私の質問は今です：

1. Container を Shared として保存し、それを使用して Resolve メソッドを介して依存関係を解決するのは正しいアプローチですか?
2. コンテナの解決動作をカプセル化する方法に問題があります。そのための正しい構文は何でしょうか? Resolve メソッドを呼び出せるようにするために各フォームで Unity を参照したくないので、独自の Resolve メソッドをカプセル化しています。このようにして、どこでもコンテナー参照を変更せずに IOC コンテナーを変更したい場合、AccountModule を別のものに簡単に置き換えることができます。

a) DDD アプリケーションがオニオン アーキテクチャを使用して実装されている場合Application layer、オニオンのApplication Service layer?

b) Onion ではObject Services layer、インフラストラクチャの動作を提供するインターフェイス (ISendEmailまたは などIRepository) を配置しますが、Onion のインターフェイスはどのような動作をApplication Service layer提供する必要がありますか?

ありがとうございました

ドメイン駆動設計を学びながら、次の解決策をまとめました (この順序は辞書順であり、依存関係を表すものではないことに注意してください)。

以下、各プロジェクトの概要です。

Domain.Models: ドメイン エンティティと値オブジェクト (例: Order)

Domain.Interfaces: ドメイン サービス インターフェイスとリポジトリ インターフェイス (例IOrderService: IOrderRepository)

Domain.Services: ドメイン サービス インターフェイスの具体的な実装 (例: OrderService)

Infrastructure.Data: リポジトリ インターフェイスの具体的な実装 (例: OrderRepository)

Infrastructure.DependencyResolution: 依存性注入の解決。

問題

今、私はドメイン以外のサービスを提供したいと考えています。例としては、電子メールを送信するための電子メール ゲートウェイがあります。このために、次のプロジェクトを作成しました。

Infrastructure.Components: 非ドメイン サービスの具体的な実装

質問

このような非ドメイン サービス (たとえば、IEmailGateway) のインターフェイスはどこに配置しますか?

Domain.Servicesプロジェクトからアクセスできる必要があるため(OrderService通知を送信する必要がある場合があります)、Domain.Interfacesに入れますか? メールの送信はドメイン固有のアクティビティではないため、NO と言います。

リポジトリ パターンを使用して、集計へのアクセスと保存を提供しています。

問題は、エンティティの関係で構成される集計の更新です。

たとえば、OrderandのOrderItem関係を考えてみましょう。集約ルートはOrder、独自のOrderItemコレクションを管理します。OrderRepositoryしたがって、 は集約全体の更新を担当します ( はありません) OrderItemRepository。

データの永続性は、Entity Framework 6 を使用して処理されます。

リポジトリの更新方法 (DbContext.SaveChanges()別の場所で発生):

上記の例では、関連するコレクションではなく、Orderエンティティのみが更新されます。OrderItem

すべてのOrderItemエンティティを添付する必要がありますか? どうすればこれを一般的に行うことができますか？