0

3 層アプリケーションがあるとします。

  1. UIレイヤー（UI）
  2. ビジネス層 (BLL)
  3. データ層 (DAL): 32 ビット DLL を参照するため、x86 としてコンパイルする必要があります

従来のアプリでは、UI は BLL を参照し、BLL は DAL を参照します。UI または BLL が "任意の CPU" プラットフォームに設定されている場合、C# コンパイラでプラットフォームの不一致に関する警告が表示されます。したがって、x86 の要件 (または「提案」、これは警告であるため) が UI に反映され、コンパイラは満足します。

IoC を使用するアプリで、すべてのレイヤーから参照される 4 番目のアセンブリ "共有インターフェイス" を追加するとします。また、UI は BLL と DAL の両方を参照し、BLL は DAL を参照しません。この場合、UI にはプラットフォームの不一致の警告が表示されます。ただし、BLL は "任意の CPU" のままで、警告を受け取らない可能性があります。残りの部分と、これが実行時エラーを引き起こす可能性があることを想像できます。

私の推論は正しいですか？IoC、またはより広義には疎結合は、その性質上、一部のエラーをコンパイル時から実行時に移動する傾向がありますか?

編集：これを再考すると、私の論理に欠陥があることに気付きました。メイン アセンブリ (UI) は、アプリが実行されるプラットフォームを決定するものです。したがって、BLL が "Any CPU" のままであっても、UI は x86 を強制し、ランタイム エラーは発生しません。さらに良いことに、BLL が共有されていて、別の DAL 実装が x86 を必要としない場合、その参照をドラッグしていないため、他のアプリは任意の CPU のままになる可能性があります。一部のコンパイラ エラーが実行時エラーに移行する他の例はありますか?

4

1 に答える 1

1

あなたの推論は、IC や疎結合とは何の関係もありません。これらのエラーは、DLL の使用方法に関係なく、32 ビット/64 ビットを混在させ始めるとすぐに発生します。エラーはアセンブリ レベルで発生し、疎結合や依存性注入のようなクラス レベルでは発生しません。

于 2013-03-12T11:50:01.557 に答える