問題タブ [repository-design]

デコレーターを使用して、アスペクト指向プログラミングをプロジェクトに適用するプロトタイプを構築しようとしています。私のプロジェクトの一部では、(単純な CRUD のために) 一般的なリポジトリを使用しますが、最終的には、コマンドおよびクエリ ハンドラーも組み込む予定です (これらは、ProcessCustomerOrders などの特定のタスクを実行します)。また、ここで例として挙げたい分野横断的な懸念事項は、セキュリティとロギングです。

また、サンプル コードは Decorator パターンを使用したものではなく、コンテキストを提供するためにこのプロトタイプ用に配置したコードの例にすぎないこともわかっています。

Proxy パターンや Code Weaving パターンなど、AOP (またはクロスカッティング コンサーン) を実装する他の方法があることは理解していますが、これらのパターンに精通していないため、それらの間のトレードオフがわかりません。

ここでコンソール アプリを使用しているのは、連鎖的に「新しく」作成した場合にどのように見えるかを示すためだけです。

私の質問は次のとおりです。

(1) Simple Injector (ブートストラップ クラス) を使用してこれを接続し、順序を同じに保つにはどうすればよいですか?

(2) これはデコレータ パターンの適切な使用法ですか (基本抽象またはインターフェイス クラスまたはデコレータ ベースを使用していないため)?

(3) 2 つの異なるバージョンを注入せずに、同じリポジトリで ILogger サービスの複数の実装 (DatabaseLogger と ConsoleLogger など) を利用するクリーンな方法はありますか?

(4) 実際のログ記録は Repository メソッドに実装され、ILogger サービスは Repository クラスに挿入されますが、ロガーを配線して汎用リポジトリを引き続き使用するよりも、これを行うためのより良い方法はありますか?

(5) このプロトタイプでのリポジトリの使用方法に基づいて、プロキシ パターンまたはコード ウィービング パターンを使用する必要がありますか?

また、このデザインに関する一般的な批評も歓迎します。

プロトタイプコード:

UPDATE @Stevenの回答に基づく：

デコレーターとリポジトリーのシンプルなインジェクター DI:

コントローラーによって呼び出されるデコレーター チェーンの順序は、コントローラー (チェック) > セキュリティ (OK の場合は続行して呼び出しを許可する) > レポ (永続化レイヤーを更新してから) > ログ (何らかの機能へ) > そして戻る必要があります。コントローラーへ。

新しいコントローラ クラス:

上記のコードの抜粋に関する質問:

戻り値に基づいてコントローラで何らかのアクションを実行したい場合 (たとえば、Security Decorator から bool を返す)、IGenericRepository インターフェイス (したがって GenericRepository クラス) を変更する必要がありますか? つまり、Repo クラスと Security Decorator クラスはどちらも同じインターフェイスを実装しているため、Security メソッドの戻り値やパラメーターを変更したい場合は、Repository メソッドも変更する必要があるのでしょうか?

また、IGenericRepository の Security 実装を Controller に渡すだけですか?

また、ロガーは次のように変更されました。

上記では、Decoratee を呼び出して、Decorator の機能を上に追加するだけです。

最後に、セキュリティ デコレータ:

上記で理解できないのは、ロガーがどこで/いつ呼び出されるのかということです。

更新 2:

Decorator パターンが正常に動作するようです。すべての素晴らしい答えをくれたスティーブンに感謝します。

プロトタイプの主な機能:

検証 (セキュリティ) デコレーター:

ロギング デコレータ:

汎用リポジトリ:

コントローラー:

ServiceStack を使用して Rest サービスを実装しています。リポジトリ パターンを使用し、リポジトリを IOC 経由でサービスに自動配線します。

現在、1 つのデータベース モデルが 1 つのリポジトリとペアになっている単純なアプローチがあります。これは、1 つのサービスで複数のエンティティが操作される場合は常に、トランザクション境界が使用されないことを意味します。リポジトリは順次呼び出されます。途中で 1 つ以上のステップが失敗した場合は、データベースを手動で初期状態に「ロールバック」する必要があります。最悪の場合、リクエスト スレッドが終了した場合、または未チェックの例外 (OutOfMemoryException など) が発生した場合、データベースは一貫性のない状態のままになります。

私は一連の仮想的な解決策を持っていますが、どれも適切ではないと考えています:

1. 接続を開き、サービス レベルでトランザクションを開始します。リポジトリを呼び出して、接続を渡します。これは、すべての ddd 設計ガイドラインに反するため、明らかに間違っています。全体のポイントは、上位層が具体的な永続性について完全に無知であることです。さらに、それは単体テストを台無しにします。
2. 最初のリポジトリでトランザクションを開始します。他の依存リポジトリが呼び出されますが、既に開いている接続が渡されます。これも悪い設計のように聞こえます。
3. 集計の定義。私はドメイン モデリングの専門家ではないので、これはあまり好きではありません。集計を導入すると、設計エラーが発生する可能性があると感じています。現行モデルの利点の 1 つは、シンプルであることです。

この問題に対する提案はありますか？前もって感謝します

私が働いている会社では、アーティファクトのようなリポジトリ管理ツールを使い始めており、このツールのユーザーガイドを読んでいます。仮想リポジトリ、いくつかのローカルおよびリモートリポジトリを作成する構成から始めました。使用ガイドで、次のことがわかりました。

リモート リポジトリ自体の所有者など、クエリを傍受できる人に、アーティファクト クエリから派生した機密性の高いビジネス情報が開示されないようにします。

これは次の方法で回避できることがわかりました

パターンを除外

仮想リポジトリの機能。これについて何か提案をいただけますか？どのような要求を避けるべきですか?

NHibernate をリポジトリ デザイン パターンと組み合わせて使用​​しています。現在のタスクでは、エンティティを更新し、同じトランザクション内の別のエンティティも削除する必要があります。私はレイターで宣言ISession.BeginTransaction()し、次のようRepository's Servicesに渡しRepository's methodます：

聞きたいことは

1. Repository's Service layer管理するISessionだけでなく、ITransactionそれを渡すのは良い考えAssociate Repositoryですか？
2. Repository's Service layerそれが良い考えではない場合、同じトランザクションでそれらのタスクを実行するために、そのトランザクションについて知らせずRepository layerにできるだけ軽量にするために、どのように設計を変更すればよいでしょうか?

編集

明確にするために、 myEntityServiceは実行business logic layerに依存するものであり、結果を（私の場合はwinform）に渡します。だから、なんとかさせてしまうと、そもそも避けたいことにつながると思いました。Repositorybusiness logicpresentation layerEntityServiceISessionITransactiontight coupling

編集2

に従ってptk93、次のように設計を変更しました。

この設計はデカップリングRepositoryに十分Repository Serviceですか?

私が始めようとしている Django プロジェクトの mercurial リポジトリを整理する方法がわかりません。これが現在の構成です。

私のワークフローについては、プロジェクトとドキュメントに関連するアクティビティを分けておきたいと思います。2 つの専用リポジトリを持つことで問題を解決できる可能性がありますが、ドキュメントとプロジェクトの両方が必要な場合は、2 つのリポジトリを複製する必要があります。上の写真。

私が欲しいものを手に入れることは可能ですか?また、プロジェクト、ドキュメント、およびリポジトリを再編成する方法はありますか?