0

ここで多くのスレッドに目を通しましたが (おそらく間違った用語を使用している可能性があります)、NInject を介して IoC を使用するように Web アプリケーションを変換しています。私の他のIoCプロジェクトはかなり小さいので大きな問題ではありませんでしたが、次の状況で推奨される方法は何ですか...

私のオブジェクトの構造は次のようになります...

public class Address
{
    public virtual string Street { get; set; }
    public virtual City City { get; set; }
}

都市はそれ自身のオブジェクトです...

public class City
{
    public virtual string Name { get; set; }
}

今、私は避けられない「オブジェクトがnullです」という例外を次のように処理しています...

public void DoThing()
{
    new Address address();
    address.Street = _street;
    address.City = new City();
    address.City.Name = _cityName;
    DoOtherThing(address);
}

小規模なプロジェクトではこれで問題ありませんでしたが、大きなプロジェクトになると非常に面倒です。(私のオブジェクトに別のオブジェクトを追加します。すべてを見つけたと仮定すると、100 か所以上でこれを行う必要があることを意味する可能性があります)

IoCの前は、これは次のようなことを行うことで簡単に処理されました...

public class Address
{
    private string street;
    private City city;

    public Address()
    {
        street = string.Empty;
        City = new City();
    }

    public string Street 
    { 
        get { return street; } 
        set { street = value; }
    }
}

私が理解しようとしているのは (おそらく、私が読んだガイドでこの詳細を完全に見逃しているだけです)、IoC で同等のことをエレガントな方法で行うにはどうすればよいでしょうか?

私がフォローしている構造は、Tony Sneed がhttp://www.develop.com/onionarchitectureで提示したものに基づいています。

唯一の注目すべき違いは、サービス レベルでまだ何も持っていないことです。これは、私たちのもののほとんどが、データベースからの読み取り/データベースへの書き込みに過ぎず、間に顕著な操作がほとんどないためです。（サービスレベルに入れる必要があるものがあるでしょうが、まだ何もヒットしていません。そのレベルとリポジトリに属する​​ものが正確にはまだ完全には明らかではありません。）

参考になる詳細があれば教えてください (IoC は正常に動作しています。保守性を適切に保つために、上記の問題に取り組む必要があるだけです)。

4

1 に答える 1

2

空のオブジェクトを作成するだけなら、IoC を使用する本当の理由はありません (より具体的な用語である依存性注入と呼びます)。ロードされた City オブジェクトを Address オブジェクトに渡すつもりでない限り、コンストラクターで new を使い続けてください。この状況で IoC/DI を使用してもメリットはありません。

実行時に依存関係をオブジェクトに渡す必要がある場合は、DI を使用する必要があります。これは技術的には依存関係ですが、単純な空のオブジェクトであるため、良い候補にはなりません。

于 2013-04-26T16:16:45.347 に答える