2011-09-09 4 views
1

conversational natural language processingのライブラリを構築しています。多くの点で、コントローラとアクションメソッドを持っている点でMVC3とよく似ています。また、コントローラクラスのコンストラクタをインスタンス化するときに、MVC3と同じように依存関係注入を使用します。主な違いは、英語の文がHTTPのURLとフォームの値の両方を置き換えることです。ルーティングは、一致する文構造に基づいています。渡されるパラメータは、英語の文章で使用される単語やフレーズの意味です。共通サービスロケータとIDependencyResolverの実装

現在、依存性注入のためにAutofacを使用していますが、その依存関係を削除して呼び出し元にDIコンテナを使用させたいと思います。

私は私の溶液中でP & P/CodePlexにCommon Service Locatorプロジェクトを使用する場合は、発信者がまだ私のエンジンによって公開されているインタフェースのインスタンスに対してIServiceLocatorの独自の実装を提供する必要があります。 MVC3からを代わりに使用する場合、そのインターフェイスへのさまざまなDIコンテナからのマッピングの少なくとも既存の実装があります。

はI必要があります: -

  1. マッピングクラスを実装するための共通サービスロケータと力の発信者を使用します。
  2. 他のコンテナへのマッピングがすでにあるMVC 3 IDependencyResolverインターフェイスを使用します。
  3. 依存関係リゾルバとしてobjectを受け入れ、私が必要とする1つの方法を得るためにダックタイプを入力するので、MVC3インターフェイスをASP.NET MVC3に依存することなく使用できます。
  4. 他?
+2

あなたの質問に答えはありませんが、ソリューション1のビューが変更される可能性があります。普及しているほとんどのコンテナで使用できるIServiceLocatorの実装があります。したがって、異なることをしたい場合を除き、独自のIServiceLocatorを実装する必要はありません。私はそれが必要かどうかわからない? –

答えて

0

共通サービスロケータは、決して変更されず、特定のバージョンを必要としないインターフェイスアセンブリです。

さらに、すべての一般的なIOCライブラリには、Common Service Locatorに接続するための実装が用意されています。

したがって、オプション1が最適なオプションであり、共通サービスロケータの新しいリリースで中断するリスクは実質的にゼロです。

Philip Laureanoありがとうございました。

関連する問題