2

Iocコンテナを使用してプロジェクト内のほとんどのオブジェクトを解決しますが、どこでも使用するのは不適切なようです。実行時に、ユーザーは単一の会社IDのコンテキストにあり、リポジトリや作業単位などのコンストラクターでその会社IDを渡すことが適切であるように思われます。実行時に会社IDのパラメーターオーバーライドを使用できますが、使用することに利点はありますか

var uow = IocContainer.Resolve<IUnitOfWork>(new ParameterOverride("companyId", companyId))

とは対照的に

var uow = new UnitOfWork(companyId)

さて、私はいつかIUnitOfWorkの別の実装を作成したいと思うかもしれないことを理解しており、新しい実装をIoc構成と簡単に入れ替えることができますが、とにかくそうすることはないと確信しています。

4

2 に答える 2

4

いいえ、電話をかけることnewがまさにあなたが望むものである場合があります。例としては、メソッド呼び出しまたは狭いスコープにローカルなオブジェクトがあります。

モデルオブジェクトは通常、IoCコンテナの制御下にはありません。起動時にIoCコンテナが認識できないユーザーから渡されたデータを使用して、新しいセッションまたはリクエストスコープごとに1つインスタンス化します。

更新：論理ユニットに関するHonzaBrestanのポイントは的を射ています。典型的なSpringレイヤーの配置は、インターフェースベースです。

view->controller->service->persistence

サービスは、他のサービス、モデルオブジェクト、および永続性を使用して、ユースケースを実現します。

于 2012-12-18T12:28:50.140 に答える
2

IoCの最大の利点は、実装のスワッピングではなく（ほとんどのプロジェクトでは、とにかくそうすることはほとんどありません）、コードをより明確な論理ユニットに分割することです。つまり、一般に、ユニットのテストと管理が容易で、全体としての理由。

そのことを念頭に置いて、プロジェクトの論理単位に応じて、「注入の粒度」を自分で決定することをお勧めします。5つの大きなモジュールの場合もあれば、数十の異なる小さなコネクタの場合もあります。また、duffymoが述べたように、newローカル/ナロースコープに必要なものかもしれません。

于 2012-12-18T12:35:36.530 に答える