5

私は、私が遊んだり学んだりしている標準の.NETMVC3リポジトリパターンプロジェクトと考えるものを持っています。それはかなり標準的な構造です。

  • リポジトリプロジェクト（下記のキャッシングインフラストラクチャを使用）
  • ドメインモデルプロジェクト
  • サービスレイヤープロジェクト
  • MVCプレゼンテーションプロジェクト

静的コンストラクターのみを持つクラスのプライベートメンバーを注入する必要があるシナリオに遭遇しました。これにより、コンストラクターの注入ができなくなります。

問題のクラスは、完了したばかりのAppFabricキャッシング実装を使用するためのラッパーです。（そのような傾向がある人のために、私の実装はhttps://github.com/geersch/AppFabricに基づいてい ます）

基本的に私は持っています：

  • インターフェイスICacheProvider
  • クラスDefaultCacheProvider：ICacheProvider
  • 静的クラスキャッシュ（私が注入した実装を利用する）

静的クラスキャッシュは、DefaultCacheProviderに解決されるICacheProviderを挿入したい場所です。

    private static readonly ICacheProvider CacheProvider;

    static Cache()
    {
        //DependencyResolver.Current.GetService<ICacheProvider>();

        //CacheProvider =
        //    (ICacheProvider)ServiceLocator.Current
        //                            .GetInstance(typeof(ICacheProvider));
    }

    public static void Add(string key, object value)
    {
        CacheProvider.Add(key, value);
    }

    public static void Add(string key, object value, TimeSpan timeout)
    {
        CacheProvider.Add(key, value, timeout);
    }

    public static object Get(string key)
    {
        return CacheProvider[key];
    }

    public static bool Remove(string key)
    {
        return CacheProvider.Remove(key);
    }

私が読んだものに基づくと、これはServiceLocatorのシナリオのように見えますが、非常に強い意見（アンチパターンなど）がいくつか見られ、それと私の知識が低いため、確信が持てません。動作する実装。

キャッシュクラスを標準クラスとして設計し、SingletonScopeにICacheProviderを挿入するというStackOverflowの推奨事項を見てきました。

kernel.Bind<ICacheProvider>().To<DefaultCacheProvider>().InSingletonScope();

しかし、私は個人的に使いやすさのために静的ラッパーを好みます。

ServiceLocatorはここに行く方法を設定していますか、それとも私が気付いていない明らかな何かがありますか？ServiceLocatorが進むべき道である場合、Ninjectとの連携を利用することはできますか？Ninjectにサービスロケーター機能があることは知っていますが、実装方法がわかりませんでした。

情報をありがとう。

4

1 に答える 1

5

あなたのアプローチには、依存性注入を提供するための制御の反転コンテナの本質が欠けていると思います。

私が読んだものに基づくと、これはServiceLocatorのシナリオのように見えますが、非常に強い意見（アンチパターンなど）がいくつか見られます。

非常に強力な意見には、通常、シングルトンパターンへの嫌悪感、つまり、静的クラスを使用してサービスを提供することが含まれます。ここでの問題は、作成したCacheクラスが、参照したアンチパターンと同じシングルトンパターンであるということです。

Cacheシングルトンを消費するコードはどのように見えますか？仮説を提案させてください。

public class SomeClass
{
    public string GetSomeMetaData()
    {
        return Cache.Get("magicKey");
    }
}

この場合、IoCを抽象化し、シングルトンを使用してDIを回避しました。私は提案します

public class SomeClass
{
    private readonly ICacheProvider _cacheProvider;

    public SomeClass(ICacheProvider cacheProvider)
    {
        _cacheProvider = cacheProvider;
    }

    public string GetSomeMetaData()
    {
        return _cacheProvider.Get("magicKey");
    }
}

現在、の消費はICacheProviderそれを必要とするクラスで直接発生し、実装への変更をより簡単に受け入れることができますICacheProvider。テストを簡素化するという追加の利点がありました。シングルトンパターンをテストすることはほぼ不可能です。

于 2011-04-22T02:43:10.307 に答える