7

デスクトップ アプリを作成しようとしています (.NET Windows フォームを使用)

基本的に、n 層のアプリを作成したいのですが、レイヤー間の疎結合も必要です。ただし、これがWindowsフォームの良いアプローチであるかどうかはよくわかりません

そして今、IoC（StructureMap、Ninject、Spring.Net）を使用することが本当に賢明な選択であるかどうか疑問に思っています。以前にAsp.Net Webアプリケーションに使用したことがありますが、今私が疑っているのは、 Windowsフォームでは、タブをナビゲートしてもビジネスエンティティが保持されます。実行される新しいリクエストごとにビジネスエンティティを挿入する必要があるWebフォームやMVCアプリとは異なり、これはAsp.Netページのライフサイクルのためですここで、初期化が実行され、インスタンス化が制御されます。

これは一種の長期開発プロジェクトであり、保守追跡、在庫、作業指示書、および管理レポートを組み合わせています。私は現在、そのアーキテクチャの提案に取り組んでいます。

IoC を使用するポイントを誤解しているのかもしれません。

任意の視点をいただければ幸いです。

4

3 に答える 3

4

あなたのケースで DI / IoC を使用することはまだ理にかなっています。なぜなら、依存関係がどこから来るのか、誰がその寿命を管理するのかなどの制御を放棄することがすべてだからです。

その意味で、原則はInversion of Controlほとんどプラットフォームに依存しません。ASP.NETWinForms

したがって、ASP.NET では通常、コントロールの反転は通常、コントローラーへのコンストラクター インジェクションなどを介して実現Dependency Injectionされますが、Windows フォームで同じパターンに従う必要があるという意味ではありません。すべてのフォームで使用できる IoC コンテナーのインスタンスを作成し、次のような方法で依存関係を取得します。

var SomeBusinessObject = container.Get<SomeBOType>(); //Ninject style.

この場合、それはまだ IoC です (フォームは依存関係を直接作成しません。コンテナーが新しいインスタンスを提供しているのか、それともグローバルに共有されている単一の静的インスタンスを提供しているのかはわかりません。それがいつになるかはわかりません)。破壊されたなど）、厳密に言えば依存性注入ではありませんが、IoC フレームワークによって管理される複雑な依存性グラフを持つことのすべての利点を得ることができます。

また、ユーザーがタブを切り替えるイベントをいつでも処理できることを覚えておいてください。それがまったく新しい「要求」であるかのように扱い、依存関係を破棄して再取得します。アプリが動作するはずです。

于 2013-11-13T13:37:48.947 に答える