2

おそらくこれは広すぎる質問かもしれませんが、何がベスト プラクティスで、何が「正しい」と考えられるかを聞きたいと思っています。同様のトピックが見つかりませんでした。これはおそらく、一般的で検索が難しいためです。

これはすべて、Windows サービス プロジェクトに別のサービスを追加したときに始まりました。以前は、メイン メソッドはコンポジション ルートと見なされていたものであり、IoC コンテナー登録コード、app.config の読み取りなどは何らかの形でメイン メソッドにありました。そこで必要な依存関係を組み立てた後Resolve、コンテナーを呼び出して実行することでサービスを作成しました。

を継承する別のクラスを作成したときServiceBase、複数のサービスが完全に異なる可能性があり、異なる初期化コードが必要になるため、メインをコンポジション ルートとして使用する意味がないことに気付きました。

私が mather で見つけた唯一の啓発的な投稿は、Mark Seemann によるものOnStartで、彼はが (その特定のケースでは) 集約ルートになると述べています。

一般的に、適切なコンポジション ルートを選択する際の最善のアプローチは何ですか? この Windows サービス シナリオを外れ値と見なし、他のプロジェクト タイプのコンポジション ルートとしてメイン メソッドを残しながら別の方法でコーディングする必要がありますか、それともすべてのコンテキストで有効なより一般的なアプローチがありますか?

おそらく、サービスが非常に異なるセットアップを必要とするという事実は、メインが構成ルートとして再び使用される複数のスタンドアロン プロジェクトにそれらを分離する必要があることを示しているのでしょうか?

通常は .Net を使用しますが、これはおそらく他の多くのプログラミング言語にも当てはまります。

4

1 に答える 1

0

メソッドは、OS が必要とする単なるフックと考えるのが最善Main()です。それが唯一の責任であるべきです。コードはできるだけ少なくし、実際のアプリケーションを開始するために必要な最小限のコードのみを含める必要があります。概念的な考慮事項にはまったく含めないでください。

于 2014-01-09T13:27:25.307 に答える