2

私には一連のクラスがあり、それぞれの役割に応じていくつかの依存関係があります。これらの依存関係はコンストラクターに注入されています。例は次のとおりです。

public class UserViewModel
{ 
    //...
    public UserViewModel(IDataService dataService,
                         INotificationService notificationService,
                         IDialogService dialogService,
                         INavigationService navigationService)
    {
        this.DataService = dataService;
        this.NotificationService = notificationService;
        this.DialogService = dialogService;
        this.NavigationService = navigationService;
    }
}

ご覧のとおり、設定する引数はいくつかあります。私は次のようなインターフェースを書くことができます：

public interface IInteractionService 
{
    public INotificationService NotificationService { get; set; }
    public IDialogService DialogService { get; set; }
    public INavigationService { get; set; }
}

挿入されたInteractionService実装をUserViewModelのコンストラクターに1つにまとめて渡します。

public UserViewModel(IDataService dataService, 
       IInteractionService interactionService) {}

次のように使用します。

this.InteractionService.NotificationService.Publish(message);

デザインパターン/原則の観点から、インターフェイスプロパティを保持するインタラクションインターフェイスの使用に問題はありますか？それともそれを見るより良い方法はありますか？

アドバイスありがとうございます...

4

2 に答える 2

3

一般に、内部にさまざまなサービスを含む「神」サービスを作成しないでください。これは、単一応答原理（SRP）に違反します。

しかし、DIがサービスのインスタンスに対してnullを注入するのはどうしてかわかりませんか？「神」サービスの作成に対してこの動作を修正する必要がありますか？

于 2012-12-29T05:33:49.637 に答える
0

IMO、コンストラクターでの依存性注入は地獄への道です。アプリケーションの存続期間中の依存関係の最終的な数を予測できますか？本当に毎回ctorのコードを変更したいですか？怠惰な初期化ではなく、本当にすべての依存関係を一度に初期化したいですか？

たとえば、MEFは、怠惰な方法でプライベートフィールドを挿入できます。

null注入値をテストするべきではありません。DIフレームワーク自体がこれらのテストを行わない場合は、それを破棄して通常のテストを使用してください。

于 2012-12-29T05:43:56.063 に答える