2

私は現在、小さなパーソナルウィンドウ（デスクトップ）.NET LOBアプリケーションを作成しています。この機会を利用して、 DIに関する知識と経験を増やしたいと考えています。アプリケーションをモデル、DAO、GUIの各部分に分けましたが、次のような分野横断的な概念を実装する方法を考えています。

  • 現在ログオンしているユーザー-次の目的で使用されます：
    • 権利の主張-アプリケーションの一部で、ユーザーが必要な権利を持っているかどうかを確認します
    • 監査-ユーザーアクションを別のデータベーステーブルに記録する
    • 等
  • 現在のアプリケーションパラメータ（構成ファイルまたはテーブルからロード）-次の目的で使用されます：
    • ビジネス戦略の定義
    • UIの定義（たとえばテーマ）
    • 等
  • ファイル/データベースログへのログ記録-次の目的で使用されます：
    • UIアクションのログ記録（ボタンのクリックなど）
    • ビジネスプロセスのログ記録（計算の結果、戦略の決定など）
    • インフラストラクチャのロギング（CRUD操作に使用されるSQL）
    • 等

現時点では、この情報を提供するためのいくつかの方法を考えることができます。

  • 静的プロパティの使用-UserEntity.Current、Configuration.Current、Logger.Currentなど。
    • 長所：
      • 実装が簡単
      • 使いやすい
    • 短所：
      • 乱雑になります
      • アプリケーションのどの部分が何を使用しているかは不明です
      • より細かい粒度が必要な場合（たとえば、アプリケーションの一部のプロセスで現在の値をオーバーライドする必要がある場合）は使用できません。
  • DIの使用-この情報を必要とする各クラスにプロパティ/コンストラクターパラメーターを与える
    • 長所：
      • クラスごとに必要なものは明らかです
      • ユニットテストは簡単です
    • 短所：
      • コンストラクターを爆発させるようです
      • クラスにデフォルトのコンストラクターが必要な場合に問題が発生します
      • クラスがサードパーティ（XAML）によってインスタンス化されるときにセットアップが難しい
  • ServiceLocatorの使用
    • 長所：
      • セットアップが簡単
      • 使いやすい
    • 短所：
      • アプリケーションのどの部分が何を使用しているかは不明です
      • より細かい粒度を設定するのは難しい（ただし不可能ではない）

私は以前にServiceLocatorを使用したことがあるので、現在ServiceLocatorに傾倒しており、非常にうまく機能しました。しかし、私はコントロールの喪失を心配しています。設計上の問題を修正しようとする代わりに、サービスロケーターにたどり着くのは非常に簡単です。

誰かが彼らの経験/知識を提供できますか？

4

1 に答える 1

2

アプローチから始めるのに最適なケースのように思えます。アプリケーションの LOB は、さまざまな非機能要件 (認証、監査、ロギングなど) とクロスカットされたビジネス機能要件に従って設計されます。

同時に、現在のアプリケーション要件の一部はによって解決できます。まず、構成ルートを特定することをお勧めします。たとえば、アプリケーションではApplication.OnStartupメソッドです。コンポジションルートを特定できる場合は、 を避けることをお勧めします。サービスロケーターは、文字通り何でも解決できるため、メンテナンスとテスト中に不必要な複雑さを追加し、依存関係の管理が複雑になります。

決定する次のステップ:依存性注入とアスペクト指向のアプローチを分離するか、組み合わせるか。どちらのアプローチにも利点と欠点があります。

分離されたアプローチを選択すると、 を使用して多くの利点を得ることができます。優れたサンプルとドキュメント、コミュニティ、すぐに使用できる側面などです。しかし、無料のものは何もありません.postsharpは無料版の機能の数が限られており、との複雑な統合しかありません.

とを組み合わせます。概念に従っている限り、実装ではなくインターフェイスへのプログラム — すべての要件を達成できます。利点: すべてのコンポーネントを 1 か所で配線できます。2 つの大きな欠点があります。1 つ目の動的プロキシは、それ自体が非常に制限されています。2 つ目は、依存性注入コンテナーと動的プロキシーの統合です。一部のコンテナーでは既に存在し、他のコンテナーではそうではありません。例: Ninject 拡張 Interception、または StructureMap と Interception 。

次のリソースを参照して、より多くの答えを自分で見つけることをお勧めします。依存性注入に関するよく書かれた本、およびインターセプトに特化した第9章のアプローチは、あなたが問題で説明したケースで非常に役立つことがわかりました。この本の著者は、依存性注入に特化した優れたブログと、依存性注入を使用したアスペクト指向プログラミングに関するビデオも持っています。

于 2012-12-30T17:17:21.283 に答える