dependency-injection - 分離された階層型アプリケーションでの DI

Question

3 つのレイヤーがあるとします。UI、ビジネス、データ。DIを使用しています。UIからデータレイヤーにアクセスできないようにしたくありません。

問題は、データ層のDI登録についてです。コンポジション ルートは UI にあり、そこでデータを参照したくありません。私はこの答えを見つけました。私が理解しているように、すべてのレイヤーを参照し、それらはレイヤーではなくライブラリであると考える必要があります。このようにして、ビジネスレイヤーがデータレイヤーまたはその他の必要なものを使用するように指定できます。結局のところ、これがDIが存在する理由です。

それは正しいのですが、問題があります。UI でデータ レイヤーを使用しないでください。しかし、ある開発者が誤って UI からデータを参照し、別の開発者がデータ層から何かを UI クラスに直接注入しました。だから彼は、私が望んでいないビジネス層をスキップしました。

このような状況をどのように処理できますか? いくつかの制限を設けたいのですが、一方で DI の柔軟性が必要です。

もちろん、依存関係を登録するためだけに別のライブラリを用意できると考える人もいます。

ここで最も良いパターンは何ですか?

Answer 1

リンク先の回答には、コンポジション ルートと UI レイヤーが同じアセンブリにあることは問題ではないことを説明する 2 つの回答があります。

• 論理レイヤーと物理境界を間違えています。アセンブリは展開ユニットであり、複数の論理レイヤーを含めることができます。レイヤーは、アセンブリ全体に分散することもできます。4+1 ビューについて考えてみましょう。コンポジション ルートは UI と同じアセンブリにある可能性がありますが、UI レイヤーにはありません。コンポジション ルートはデータ アクセス レイヤーに依存しますが、UI レイヤーはそうではありません (そのアセンブリはそうします)。
• コード レビューを実施することは、ソフトウェアの品質とチーム内での知識の共有にとって重要です。現在コード レビューを行っていない場合は、必ず開始する必要があります。これらのコード レビューには、質問で説明したルールなど、アーキテクチャ ガイドラインのチェックを含めることができます。
• アセンブリの分離によりコンパイル時のサポートが提供されますが、ほとんどのアーキテクチャ ルールはコンパイラによってチェックできません。さらに、開発者が DAL アセンブリへの参照を追加しても、コンパイラは文句を言いません。開発者は常にルールを破る方法を見つけます。繰り返しになりますが、コード レビューは大いに役立ちます。さらに、アーキテクトとして、NDepend などのツールを使用して、いくつかのアーキテクチャ ルールの検証を自動化することもできます。ただし、コンストラクター インジェクションを適用すると、UI レイヤーの型のコンストラクターを反映するだけで依存関係を見つけることができるため、単体テストも使用できます。

しかし、これが問題だと思われる場合は、UI レイヤーを独自のアセンブリに移動してみませんか? スタートアップ アセンブリに UI レイヤーは必要ありません。Windows フォーム アプリケーションを作成する場合は、すべてのフォームを独自のアセンブリに移動します。ASP.NET MVC アプリケーションを作成している場合は、コントローラーとビューを独自のアセンブリに移動します。構築しているアプリケーションのタイプによっては、これを機能させるために特定のトリックを適用する必要がありますが、.NET のほとんどのプロジェクト タイプではこれが可能です。

本当の問題は、これは苦労する価値があるかということです。コードレビューをしなくて済むようにするためにこれが必要な場合は、自分をだましています。