10

ninject を使用して依存関係を注入するコードがいくつかあります。これらの依存関係は実際の文字列です。これは、たとえば新しいオブジェクトを作成するのではなく、文字列を挿入するためのアンチパターンですか?

つまり、Username と Password を注入したかったのですが、実際には、Usernamd と Password の 2 つのプロパティを持つ credentials という小さなクラスを作成し、これを注入する方がよいでしょうか?

コンストラクターへの文字列の注入は、

kernel.Bind<IUser>().To<User>()
      .WithConstructorArgument(@"username", configuration.Username)
      .WithConstructorArgument(@"password", configuration.Password);

このコードは臭いですか？

私がやっていることに関するアイデアや改善点はありますか?

4

6 に答える 6

8

ここで使用することをお勧めしToMethod()ます：

kernel.Bind<IUser>()
      .ToMethod(ctx => new User(configuration.Username, configuration.Password));

コンストラクターに他の依存関係がある場合は、User@jgauffin の回答に従います。

あなたはまだ使用できToMethod()ますKernel：

kernel.Bind<IUser>()
      .ToMethod(ctx => new User(configuration.Username,
                                configuration.Password,
                                ctx.Kernel.Get<Foo>()));
于 2013-09-11T11:11:08.180 に答える
3

このコードは臭いですか？

はい。を作成するConfigurationRepositoryか、異なるサービスを作成するファクトリ/ビルダー (2 つの異なる設計パターン) を作成し、代わりにそのファクトリ/ビルダーをコンテナーに登録します。

私もこのコードに問題がありました：

kernel.Bind<IUser>().To<User>()
      .WithConstructorArgument(@"username", configuration.Username)
      .WithConstructorArgument(@"password", configuration.Password);

IoC コンテナーは、主にドメイン エンティティの作成には使用されませんが、サービス/リポジトリ/コントローラーなどの作成に使用されます。つまり、アプリケーションのフローを制御するオブジェクトの作成に使用されます。

于 2013-09-11T10:28:50.113 に答える
0

プリミティブ型の注入を避けるために、私は多大な努力を払っています。

あなたが投稿したコードを見ると、私の最初の本能は、「IConfigurationService」を作成し、必要に応じてそれを挿入することです。そのサービスには、ユーザー名とパスワードのプロパティが含まれます。

于 2013-09-11T18:30:59.720 に答える
0

ここには2つの質問があるようです：

  1. プリミティブを注入するのはコード臭/アンチパターンですか?
  2. ユーザー名とパスワードの文字列を構成するために、ある種のタイプを作成する必要がありますか?

これらはまったく別の問題です。まず、依存関係は依存関係です。複雑または原始的なものになる可能性がありますが、依存関係の管理は一貫している必要があります。IoC コンテナーを使用している場合、プリミティブを挿入することは絶対にコード臭ではありません。IoC コンテナーとコンポジション ルートは、すべてのサービスのニーズとそれらを満たす方法を理解するコードの特権部分です。概念的には、これは複合型とプリミティブ型に当てはまります。ただし、実際には、複雑な依存関係とプリミティブな依存関係を登録するための異なるメカニズムがあります。リストした引数名のアプローチは完全に有効です。他のアプローチは、引数のインデックスに依存します。この 2 つのどちらかを選択するのは分かれ道ですが、最終的には、ワイヤーアップ コードを変更せずに、コンストラクターの引数の名前を変更するか、コンストラクターの引数を並べ替える自由が必要かということになります。

別の方法は、具体的な依存関係 (さらに悪い場合はサービス ロケーター パターン) を持つことです。これは、判読できない泥のボールへの滑りやすい斜面です。

次に、2 つの文字列を 1 つの型に構成する必要があるかどうかは、これらの値を一緒に使用する頻度と、どの程度 DRY にするかによって異なります。ある時点で、DRYness を追求しても利益が減少します。また、値が常に一緒に注入される場合は、単純に Ninject 構成呼び出しをリファクタリングすることを検討してください。何を選択するにせよ、その根拠がコードベース全体で一貫していることを確認してください。

最後のポイントとして、IoC コンテナーを使用してエンティティを管理することは、コードの臭いと見なされます。通常、エンティティは、ドメイン アクションを実行している間、ドメインの不変条件を維持する責任があります。（サンプルコードスニペットのコンテキスト/意図がわからないため、代替手段を提供できません。）

于 2014-08-28T18:10:36.760 に答える