0

私は (やや) DI に慣れていないので、維持しているコードベースで DI がどのように/なぜ使用されているかを理解しようとしています。ストアド プロシージャの呼び出しからドメイン オブジェクトにデータをマップする一連のクラスを見つけました。例えば：

Public Sub New(domainFactory As IDomainFactory)
  _domainFactory = domainFactory
End Sub

Protected Overrides Function MapFromRow(row As DataRow) As ISomeDomainObject
  Dim domainObject = _domainFactory.CreateSomeDomainObject()
  ' Populate the object
  domainObject.ID = CType(row("id"), Integer)
  domainObject.StartDate = CType(row("date"), Date)
  domainObject.Active = CType(row("enabled"), Boolean)

  Return domainObject
End Function

IDomainFactory は Spring.Net で注入されます。その実装には、さまざまなドメイン オブジェクトの新しいインスタンスを返す一連のメソッドしかありません。例えば：

Public Function CreateSomeDomainObject() As ISomeDomainObject 
  Return New SomeDomainObject()
End Function

上記のコードはすべて、役に立たないというよりも悪いと思います。従うのは難しく、何の価値もありません。さらに、私が知る限り、DI は実際にはローカル変数を対象としていないため、DI の誤用です。さらに、ドメイン オブジェクトの複数の実装は必要ありません。単体テストは行いません。たとえそうしたとしても、ドメイン オブジェクトをモックすることはありません。上記のコードからわかるように、ドメイン オブジェクトへの変更は SP への変更の結果であり、MapFromRow メソッドをとにかく編集する必要があることを意味します。

とはいえ、このナンセンスを取り除かなければならないのか、それとも驚くほど素晴らしいことをしているのに見逃しているのでしょうか?

4

1 に答える 1

0

依存性注入の背後にある考え方は、クラス (または別のコード) をインターフェイスの特定の実装から独立させることです。上で概説したクラスは、どのクラスが を実装しているかを知りませんIDomainFactory。具体的な実装は、そのコンストラクターを介して注入され、後でメソッドによって使用されMapFromRowます。ドメイン ファクトリは、ISomeDomainObjectこれも不明な実装を返します。

これにより、上記のクラスを変更することなく、これらのインターフェイスの別の実装を補完できます。これは単体テストでは非常に実用的です。IDatabasemethod を定義するインターフェースがあると仮定しましょうGetCustomerByID。データベース内の特定の顧客レコードに依存するため、この方法を使用するコードをテストするのは困難です。これで、物理データベースにアクセスしないコードによって生成された顧客を返すダミー データベース クラスを挿入できるようになりました。このようなダミー クラスは、多くの場合、モック オブジェクトと呼ばれます。

ウィキペディアの依存性注入を参照してください。

于 2012-11-15T19:50:28.987 に答える