MVC3 + Unityプロジェクトの効率を改善しようとしています

Question

私は依存性注入にUnityを使用するMVC3プロジェクトを持っています。

メインMVC3プロジェクト、MVC3とデータ層の間にある「ドメイン」クラスライブラリ、およびデータ層を構成するクラスライブラリの束があります。

（MVC3） - （ドメイン） - （データ層）

これは、ドメインクラスのサービスコンストラクタの一つの例である：コントローラを有する呼び出されるたび

public DomainModelCacheServices(
    Data.Interface.ICountryRepository countryRepository, 
    Data.Interface.ILanguageRepository languageRepository, 
    Data.Interface.ISocialNetRepository socialNetRepository 
) 

DomainModelCacheServicesのコンストラクタに新しいDomainModelCacheServicesオブジェクトが作成され、DomainModelCacheServicesのコンストラクタに3つのリポジトリクラスが作成されます。

私はこれが効率的だとは思いません！

これを悪化させるのは、クラスDomainModelCacheServicesがキャッシュクラスであることです。変更されないデータのリストをロードし、それらを静的として保持します。しかし、すべての参照に対して3つのリポジトリクラスを構築する必要があります。

シングルトン（永遠）のライフタイムをDomainModelCacheServicesに与えると、スレッドセーフであることを保証する必要があります。また、何百ものヒットを得る日が来たら、多くのロックが発生します。

私はこれにコンストラクタを変更することができます：

public DomainModelCacheServices(
     IServiceLocator serviceLocator 
    ) 

私はなぜ知らないが、これは右見ていません。コンストラクタは目には無意味になり、ドメインクラスでUnityを参照する必要があり、何らかの理由でMVC3アプリケーションが所有するServiceLocatorをドメインクラスに認識させる必要があります。多分ゆるいカップリングが緩すぎるかもしれませんか？

これらのクラスをすべて構築することは、それほど効率的ではないようですが、私はそれについて心配するべきではありませんか？

ユニティが「遅延」コンストラクタパラメータをサポートしていればいいと思います。しかし、それはしません。

MVC3 + Unityプロジェクトをより効率的に、具体的にはドメインモデルの設計にする方法に関するアイデアはありますか？

読んでいただきありがとうございます！

Answer 1

偉大な推論。

ただし、オブジェクトを作成するのは安価です。静的フィールドのすべてのオブジェクトを既にキャッシュしているので、私はシングルトンを作成しません。現在のアプローチは理解しやすいです。

なぜあなたはあなたのリポジトリクラスでキャッシングされていません。

私はあなたのために別の質問を得ましたか。

リポジトリはデータの責任を負い、すべてのデータ処理は他のすべてに対して透過的でなければなりません。また、データソースの更新を担当するため、すべてが簡単になります。今日の変更とキャッシュをどのように同期させますか？ドメインイベントを通して？

リポジトリのプライベートフィールドとして使用するキャッシュクラスを作成します。

Answer 2

キャッシュはドメインレベルではなく、リポジトリ実装レベル（DALの場合）で定義する必要があります。したがって、たとえばICountryRepositoryは、DALに2つの実装が必要です。CountryRepositoryおよびChachedCountryRepository。 Unityのがデコレータとしてに配線されている必要があります（CountryRepositoryはChachedCountryRepositoryです）。 CachedCountryRepositoryはデータがキャッシュにあるかどうかをチェックし、そうでなければコールを内部CountryRepositoryに渡します。

オブジェクトを作成するのは高価ではなく、キャッシュが正しく定義されているため、問題についてはあまり気にしません。