inversion-of-control - 制御の反転とRAIIは一緒にプレイできますか？

Question

制御の反転（IOC）について読んでいたところ、メモリ管理が面倒になっているように思われました。もちろん、iocは主にガベージコレクション環境（Net、Java、Scripting）で使用されているようですが、私の懸念は非gc設定です。

ここでの私の懸念は、リソースの有効期間をオブジェクトの有効期間から切り離すため、IOCがRAIIに反することです。この追加された複雑さは他の誰かを悩ませませんか？そして本当の問題は、物事をスムーズに進めるためにどのような技術を使用できるかということです。

score 3 · Accepted Answer

このため、私は独自のIoCコンテナーを作成しました。このコンテナーは、（C＃/。NETで）使い捨てのサービスラッパーを返します。このラッパーは、破棄されると、サービスに関して「正しいことを行います」。

それである：

次の場合は何もしません。
- オブジェクトはIDisposableを実装していません
- コンテナスコープではありません（この場合、コンテナはそれを追跡し、同じオブジェクトを複数回返します。コンテナが廃棄されると、オブジェクトも返されます）
- プールされていません
- シングルトンスコープではありません（コンテナースコープと同じですが、コンテナーの階層により、シングルトンスコープのサービスが最上位のコンテナーに格納されます）
サービスを破棄します（ファクトリスコープがあり、IDisposableを実装します）
プールに戻す

これは、私のサービスを使用するすべてのコードがusing-block内にあることを意味しますが、少なくとも私にとっては、その意図はより明確です。

using (var service = container.Resolve<ISomeService>())
{
    service.Instance.SomeMethod();
}

基本的には、サービスを解決し、サービスインスタンスでSomeMethodを呼び出してから、サービスを破棄します。

サービスインスタンスを破棄するかどうかの知識はコンシューマーには利用できないため、IDisposableの実装を完全に無視するか、IDisposableを実装するすべてのサービスを破棄するかを選択できました。どちらも私にとって良い解決策ではありませんでした。3番目の選択肢は、ラッパーが破棄された後、サービスをどう処理するかを知っているオブジェクトでサービスインスタンスをラップすることでした。

score 1 · Accepted Answer

はいといいえ。IoCは、リソースの有効期間をオブジェクトの有効期間から切り離すのではなく、メソッド呼び出しスコープをオブジェクトの有効期間から切り離します。メソッドの最後に破棄されるオブジェクトを、別のIoC呼び出しが行われるまで存在させたい場合がよくあります。したがって、メソッドのローカルをクラススコープに移動し、メソッドが再入可能でないことを確認するか、オブジェクトを所有して破棄できるように追加の「環境」を渡すなど、別のアプローチを採用する必要があります。後続のIoCメソッド呼び出しで。汎用のイベント駆動型システムが必要な場合、どちらのアプローチも非常に複雑になります。モデル自体が明示的な再帰と反復を実装する必要があります。代わりに親族。

score 0 · Accepted Answer

私が最初に思いついたのはSmartPointersでした。そしてテンプレート引数。しかし、テンプレート引数がIOC手法としてカウントされるかどうかはわかりませんが、カウントする必要があると思います。少なくともこれらはIOCのいくつかの問題を軽減することができますが、アイデアで完全に売れるわけではありません。

inversion-of-control - 制御の反転とRAIIは一緒にプレイできますか？

3 に答える 3

Related

Reference