制御の反転を正しく使用しようとしています。私のアプリは正常に動作しています。私はUnityをIoCコンテナとして使用しています。しかし、どの具体的なクラスを使うかという選択肢があるときは間違っていると思います。制御と選択の反転
この例では、特定のデータソースからデータを取得するクラスがあります。ファイルタイプによって、データアクセサークラスが呼び出されます。
このサービスクラスは、型をチェックし、切り替えを行い、次にどの具体的なクラスを使用するかを選択します。
しかし、ここではIoCの原則を壊しているようです。クラス内の何かを「新しくする」ことです。私はこのサービスクラスにはもはや注入しません。なぜなら、現時点では、私がどのファイルタイプで作業しているのかを決定していないからです。だから、私は「注入」をコメントしなければならず、かなりハードコードしなければならなかった。
ここにコードを抽出します。
public class DataService : IDataService
{
IFileReader _fileReader;
public DataService(IFileReader fileReader)
{
// _fileReader = fileReader;
}
/// <summary>
/// Returns reporting data based on a group of export files.
/// </summary>
/// <param name="files">A list of files to analyse</param>
/// <returns></returns>
private List<RawFileData> GetRawData(string[] files)
{
foreach (var file in files)
{
// validate files exists.
switch (GetFileType(Path.GetFileName(file)))
{
case "CSV":
{
fileIsOK = true;
_fileReader = new CSVileConnector();
break;
}
case "TXT":
{
fileIsOK = true;
_fileReader = new TXTFileConnector();
break;
}
default:
break;
}
if (fileIsOK)
{
var finedata = _fileReader.ReadData(file);
data.Add(new RawFileData
{
DataItems = finedata,
FileName = file
});
}
}
return data;
}
これは、このような状況を処理する正しい方法ですか?クラス作成時に、どの子クラスが「依存する」のか分かりません。そしてそれを論理で決定し、正しいConcreteクラスを新しくしますか?
おそらく、iocはルールではないだけのことです。 –
ええ、これは真実かもしれない - それゆえ私がなぜそれを原則と呼んだのか。しかし、できる限り原則に固執するのは良いことです。私はやっていることが正しいかどうかを確認しています - それを行うより良い方法があります。サービス層がデータ型を決定しないようにすることができます。これはデータレイヤーで行う必要があります。ちょっとしたケースでは、私の「スイッチ」がレイヤーを下に移動し、IoCがここに戻ります。しかし、私はデータ層で同じ問題を抱えています。私はその下の正しい具体的なクラスを新しくする必要があります。 – Craig