5

リポジトリ パターンを使用してエンティティに「ビジネス ロジック」を追加する拡張メソッドを備えた静的クラスをいくつか取得しました。

IRepositoryこれらの拡張機能で新しいものを作成する必要がある場合があります。

私は現在、拡張しているオブジェクトを介して Ninject カーネルにアクセスすることで回避していますが、それは本当に醜いです:

public static IEnumerable<ISomething> GetSomethings(this IEntity entity)
{
    using (var dataContext = entity.kernel.Get<IDataContext>())
        return dataContext.Repository<ISomething>().ToList();
}

また、ファクトリから何らかの形で Ninject カーネルにアクセスする静的コンストラクターを作成することもできますが、Ninject 2 にはそのためのインフラストラクチャが既にありますか?

誰もがより良い解決策を知っていますか? ビジネスロジックを実装するこの方法について、誰かコメントはありますか?

4

1 に答える 1

4

拡張メソッドの問題とそれらがどのようにものを取得するかについて。2つのアプローチがあります。

  1. サービスの場所-グローバルカーネルを持ち、サービスの場所にドロップダウンします（これは依存性注入とは異なります）。ただし、ここでの問題は、エンティティ（またはその拡張機能）がそのコンテキストを想定するのではなく、代わりにそれを要求する必要があることです。

  2. あなたは拡張メソッドなので、拡張しているものが必要なものを渡します

ご想像のとおり、これ（ダンプグラウンドとなるグローバルカーネルを持つ）は、Ninjectがあなたを思いとどまらせようとするものです。一般に、使用しているもの（MVCやWCFなど）の拡張機能は、適切な場合に何かを提供します。たとえば、WCF拡張機能にはhttp://github.com/ninject/ninject.extensions.wcf/blob/master/source/Ninject.Extensions.Wcf/NinjectServiceHost.csがあります

ここでのより大きな問題は、このような依存関係はおそらくエンティティレベルまで伝播されるべきではないということです。つまり、サービスレベルにとどまり、そこから伝播される必要があります（DDDボキャブラリーを使用）。

この答えは、この分野を少しカバーしているので、私にとって興味深いと思うかもしれません（アーキテクチャの概念の観点からのNinjectテクニックからの詳細）

于 2010-05-14T14:25:42.607 に答える