2

最近、MVC3とNinject2に移行しました。ほとんどのコードでコンストラクターインジェクションを使用していますが、Inject属性を使用しなければならない場所もあります。Ninject2は独自のIDepencyResolverインターフェースを登録します。DependencyResolverクラスが名前空間の一部であるのは好きSystem.Web.Mvcではありません。その機能はMVCと厳密には関連していないためですが、現在、クラスが存在する場合は、次のことができます。

public SomeClass 
{
    public IUserService UserService { get; set; }

    public SomeClass()
    {
        UserService = DependencyResolver.Current.GetService<IUserService>();

それ以外の

public SomeClass 
{
    [Inject]
    public IUserService UserService { get; set; }

Ninjectしたがって、クラスで名前空間を参照する必要はありません。DependencyResolverそのように使用する必要がありますか？

4

3 に答える 3

5

プロパティインジェクションは、クラスの適切な動作に必要ではない依存関係にのみ使用しますが、ユーザーが設定すればいくつかの機能を追加できます。そのような機能の例はロギングです。したがって、ユーザーが独自の実装を提供できるロガーを表すプロパティを作成できます。ロガーがいない場合、クラスは引き続き正常に機能しますが、ログには記録されません。

他のすべてには、コンストラクターインジェクションを使用します。このようにして、このクラスが他のサービスに必要な依存関係を持っていることをコンシューマーに示します。

だから、プロパティインジェクションについてのあなたの質問に答えるために、私は単に持っているでしょう：

public SomeClass 
{
    public IUserService UserService { get; set; }

    public void SomeMethodWhichDoesntEnforceUserService()
    {
        if (UserService != null)
        {
            // Provide some additional functionality
        }
    }
}

また、ユーザーサービスがないとクラスが正しく機能しない場合は、次のようになります。

public SomeClass 
{
    private readonly IUserService _userService;
    public SomeClass(IUserService userService)
    {
        _userService = userService;
    }

    public void SomeMethodWhichRequiresTheService()
    {
        _userService.DoSomething();
    }
}

したがって、どちらの場合も、DIの詳細への参照はありません。それが制御の反転のすべてです。

于 2011-02-16T17:59:31.873 に答える
1

IUserService私が尋ねる最初の質問は、なぜintoのコンストラクタインジェクションを実行できないのかということSomeClassです。デザインに問題がある可能性があります。

への直接参照を回避するためにDependencyResolver、DIフレームワーク上にサービスロケーターの何らかの形式の抽象化を実装できます（例：CommonServiceLocator）が、この質問への回答が示すように、DIを正しく実行する場合はそのような抽象化は必要ありません。代わりに、アプリケーションの設計を調整する必要があります。

于 2011-02-16T17:48:24.417 に答える
0

mvc3のninject.web.mvcバージョンは、フィルター属性へのコンストラクターインジェクションをサポートするようになったと思います。試しましたか？

于 2011-02-16T18:01:00.420 に答える